[Laszlo-dev] For Review: Change 20080405-ptw-k Summary: Fix components that use JS classes

[André Bargull]

Hm, I've just started to re-write drawview as a normal lzx-class, but I 
needed to suspend that idea after a few lines:
The current lfc-like drawview implementation uses the "static" 
qualifier, but that's currently not available in the lzx-world, right!?


On 4/6/2008 6:23 PM, André Bargull wrote:
> Concerning drawview:
> I guess that needs/should be rewritten nevertheless, because of the 
> heavy use of "lz.drawview.addProperty(..)", not really a good JS2 
> class-style.
>
> Generally, what information do you need at compile time to add 
> automatically that prefix "$lzc$class_" to a class name?
> And how are lzx-interfaces processed by the compiler? Is that 
> interface definition only needed for the tag-compiler, so it knows 
> that i.e. drawview extends LzView and is has got a few attributes and 
> methods. Or is it a 'real interface', like in Java?
>
>
> On 4/6/2008 5:49 PM, P T Withington wrote:
>> I'm open to ideas, but there are a number of these conventions that 
>> you 'just have to know' if you are writing a class to implement a 
>> tag.  It's not expected that the LZX programmer will be doing this -- 
>> they should just use the <class> tag, which will handle all these 
>> conventions for them.
>>
>> In these particular cases, what is really happening is that someone 
>> has effectively broken a piece of the LFC out as a component, so that 
>> it is only loaded when needed.  And in this case, they have written 
>> an LFC-style class, which does require that they understand the inner 
>> workings of how an LFC class is used to implement a tag.
>>
>> On 2008-04-06, at 11:21 EDT, André Bargull wrote:
>>> Approved, as usual I have no idea regarding the compiler-stuff, but 
>>> hey, drawview works again!
>>>
>>>> // Classes that implement an interface must obey the LZX
>>>> // tag->class mapping convention
>>> Should I file an improvement request, so the compiler will perform 
>>> this mapping automatically, because writing "$lzc$class_foobar" 
>>> isn't really intuitive.
>>>
>>>
>>> On 4/5/2008 8:26 PM, P T Withington wrote:
>>>> Change 20080405-ptw-k by ptw at dueling-banjos.local on 2008-04-05 
>>>> 14:12:50 EDT
>>>>    in /Users/ptw/OpenLaszlo/ringding-clean
>>>>    for http://svn.openlaszlo.org/openlaszlo/trunk
>>>>
>>>> Summary: Fix components that use JS classes
>>>>
>>>> Bugs Fixed:
>>>> LPP-5700 'drawview broken'
>>>>
>>>> Technical Reviewer: a.bargull at intensis.de (pending)
>>>> QA Reviewer: promanik (pending)
>>>>
>>>> Details:
>>>>    NodeModel: Consider interfaces and mixins for getParentClassModel
>>>>
>>>>    ClassModel: Store the 'kind' (class, interface, mixin), don't
>>>>    generate any code for interfaces (for now).
>>>>
>>>>    drawview, richinputtext, lazyreplicator, replicator: Obey the new
>>>>    LFC tag class conventions.
>>>>
>>>> Tests:
>>>>    drawview examples work again
>>>>
>>>> Files:
>>>> M      WEB-INF/lps/server/src/org/openlaszlo/compiler/NodeModel.java
>>>> M      WEB-INF/lps/server/src/org/openlaszlo/compiler/ClassModel.java
>>>> M      lps/components/extensions/drawview.lzx
>>>> M      lps/components/extensions/views/richinputtext.lzx
>>>> M      lps/components/utils/replicator/lazyreplicator.lzx
>>>> M      lps/components/utils/replicator/replicator.lzx
>>>>
>>>> Changeset: 
>>>> http://svn.openlaszlo.org/openlaszlo/patches/20080405-ptw-k.tar
>>>>
>>
>>
>