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

[André Bargull]

Btw, to be able declare something as "static" was also requested a few 
times in the forum.

> The only other one I see is  "uid", which may be possible to store
>  some other way.  Maybe we need a UID generator API for the LFC ?
There'll be another one: "_colorcache". Because I've just send a 
changeset to declare it as static; atm it's implicitly static as it is 
only defined on the prototype object.

On 4/6/2008 6:55 PM, Henry Minsky wrote:
> Or maybe we should add "static" as an option to declaring an
> <attribute> in LZX?
>
>
> On Sun, Apr 6, 2008 at 12:54 PM, Henry Minsky <henry.minsky at gmail.com> wrote:
>   
>> I don't think we have any way to declare a static var in a LZX class.
>>
>>  But maybe you don't need them? What does drawview have that needs to
>>  be a static var?
>>  The 'tagname' and 'attributes' declarations will be supplied by the
>>  compiler automatically.
>>  The only other one I see is  "uid", which may be possible to store
>>  some other way.  Maybe we
>>  need a UID generator API for the LFC ?
>>
>>
>>
>>
>>
>>  On Sun, Apr 6, 2008 at 12:41 PM, André Bargull <a.bargull at intensis.de> wrote:
>>  > 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
>>  > > > > >
>>  > > > > >
>>  > > > >
>>  > > >
>>  > > >
>>  > > >
>>  > >
>>  > >
>>  >
>>
>>
>>
>>  --
>>  Henry Minsky
>>  Software Architect
>>  hminsky at laszlosystems.com
>>
>>     
>
>
>
>