[Laszlo-dev] publishing the lz.* names (LPP-6600)

[André Bargull]

>
> lz.BrowserService = LzBrowserService
This mapping does not exist. There is just "lz.Browser" which is the 
shorthand form for "LzBrowserService.LzBrowser".

So, we got only 3 types of mapping:
1) tagname to classname (lowercase)
2) singletons (camelcase)
3) "lz.embed" (lowercase, but not a tagname)

And we need to decide how to add:
- css-classes (LzCSSStyleSheet, LzCSSStyleRule, LzCSSStyleClass, 
LzCSSStyleDeclaration) /(are all css-classes public?)/
- data-classes (LzDataNode, LzDataNodeMixin, LzDataElement, 
LzDataElementMixin, LzDataText)
- core-/event-classes (LzEventable, LzDeclaredEventClass, LzEvent, 
LzDelegate)
- LzFont (documented as a tag, but not implemented as a subclass of 
LzNode..)
- other (LzURL, LzFormatter)
to the "lz"-object (see 
"http://www.openlaszlo.org/jira/secure/attachment/12000/LPP-6613.pdf").

> I'd say keep the camel case for non-tag classes (services). So, it'd  
> be "lz.view" and then "lz.BrowserService" etc. All LFC tag, public API  
> classes, and public objects wind up under "lz.", but only tag names  
> are declared as lower case.
>
> Q: Does there even need to be an "LzView" or "LzBrowserService" for  
> purposes other than supporting old code? In other words, why is a map  
> or transform needed at all if the tag classes can be declared as  
> lz.view and used that way throughout the LFC, while lz.BrowserService  
> et al are declared that way?
>
> [This whole thing needs a shakeout in the context of namespaces and  
> packages... someday...]
>
> On Jul 7, 2008, at 4:51 PM, P T Withington wrote:
>
>   
>> > On 2008-07-07, at 19:26 EDT, David Temkin wrote:
>> >
>>     
>>> >> I think we want to prefer the tag name of the LFC class to the  
>>> >> "new" class name (upper/lower) -- always.
>>> >>
>>> >> meaning, it's "lz.view" instead of "lz.View"... "lz.inputtext"  
>>> >> instead of "lz.InputText", and so on
>>> >>
>>> >> What would the implications of this change be, other than changing  
>>> >> the (new) left nav?
>>>       
>> >
>> > We're working on that.
>> >
>> > The question on the table is whether we should be distinguishing  
>> > 'tag classes', 'other LFC public API classes', and 'LFC public API  
>> > objects' by casification in the `lz` namespace, or if they should  
>> > just all be uniformly lowercased.
>> >
>> > Currently 'tag classes' are referred to by their lowercase tagname  
>> > (e.g., lz.view = LzView), singletons and the class they are  
>> > instantiated from are camel-cased (e.g., lz.Browser =  
>> > LzBrowserService.LzBrowser and lz.BrowserService = LzBrowserService).
>> >
>> > Having this non-uniform mapping means we have to manually create and  
>> > maintain the map or the doc tool has to be smart enough to spot the  
>> > creation of `lz` entries.  In either case, I don't think we are  
>> > going to completely solve the terminology issue in time for a 4.1.1,  
>> > since we would have to revise all the prose documentation, in  
>> > addition to making the doc tool make the appropriate transformation  
>> > on the generated reference.
>>