[Laszlo-dev] What is a node? [Was For Review: Change 20070806-hqm-8 Summary: make base abstract LzDataProvider class]

[Raju Bitter]

This is discussion is very interesting for me. When learning LZX (without
being aware of the implementation) a programmer indirectly experiences the
concepts you are mentioning here.

It would be helpful to have this information available in a section for
advanced programmers in the developers guide, something like the "concepts
behind LZX". It is a very logical construct, and knowing the logic will
definitely help developers to become better coders. :)

I haven't read the latest documentation, maybe we have a section like that
already. John?

- raju 


> Von: P T Withington <ptw at openlaszlo.org>
> Datum: Mon, 6 Aug 2007 22:38:00 -0400
> An: Pablo Kang <pkang at laszlosystems.com>
> Cc: Henry Q Minsky <henry.minsky at gmail.com>, Laszlo-dev bug reporting
> <laszlo-dev at openlaszlo.org>, P T Withington <ptw at laszlosystems.com>
> Betreff: [Laszlo-dev] What is a node? [Was For Review: Change 20070806-hqm-8
> Summary: make base abstract LzDataProvider class]
> 
> To me, a node is an element in the DOM.  It has a parent and
> children.  Nodes get created by LZX tags.  They don't participate in
> layout (only view and their subclasses do), but you can navigate to
> them in the DOM.  To me, that is the primary purpose of node-ness:
> that you can navigate to/from the node in the DOM, you can ask for
> the node's parent, etc.
> 
> Constraining an attribute to an expression is a feature of the LZX
> language.  Since the only thing in LZX that can have attributes is a
> node, that nifty constraint language also requires node-ness.  But we
> could think about separating that out.  Henry has asked that we
> invent a Javascript syntax to write constraints as concisely as we do
> in LZX.
> 
> But, the elements of a constraint expression do not have to be a
> node.  See, for example, LzGlobalMouse.  You can constrain a view
> attribute to the mouse position, even though the mouse is not a node.
> 
> By the same token, the LZX language makes sending an event when you
> use setAttribute on an attribute automatic.  Again, in LZX you have
> to be a node to call setAttribute.  This would be another thing we
> could extend to Javascript if we wanted.
> 
> Again, you do not have to be a node to send events.  Again,
> LzGlobalMouse is an example of an existing object that is not a
> node.  You can request to be notified of mouse events even though the
> mouse object is not a node.
> 
> There are already Javascript classes that the LZX developer has to
> know about, so this is not a new concept, although admittedly, it is
> not the usual case.  The LZX developer already has to write
> Javascript to implement methods, initialize attributes, handle
> events, etc.  Javascript is a part of the LZX language.  It is not a
> secret.
> 
> If we want to improve the performance of LZX programs, we need to
> stop using a sledgehammer where a tack hammer will do.
> 
> On 2007-08-06, at 20:24 EDT, Pablo Kang wrote:
> 
>> I'm ok with writing script as long it's documented as such.
>> 
>> I do think this would be a departure from current recommended LZX
>> coding practices. As I understand it (from Sarah and David), the
>> policy is to make everything as LZX friendly as possible.
>> 
>> I'm assuming if datarequest and dataprovider don't extend from node
>> this also means that they can't be constrained to or don't
>> participate in the event system, right?
>> 
>> pablo
>> 
>> On Mon, 6 Aug 2007, P T Withington wrote:
>> 
>>> Right.  That is the question I am asking.  Is the script tag not
>>> sufficient? This seems like a 'experts only' area, where the
>>> script tag should be fine, to me.  Given that nodes are heavy, I
>>> would avoid making things a node if I didn't have to.
>>> 
>>> On 2007-08-06, at 19:48 EDT, Pablo Kang wrote:
>>> 
>>>> This is so I can extend datarequest and dataprovider using LZX in
>>>> diamond. The other option is that I extend these classes using a
>>>> script tag.
>>>> On Mon, 6 Aug 2007, P T Withington wrote:
>>>>> Question:
>>>>> Is there a reason to make dataprovider a node?  Does it need to
>>>>> show up in the DOM, or is it just a property of a dataset?  Do
>>>>> we really need to extend it in LZX, or is making it extensible
>>>>> only from script sufficient? It seems that the answer should be
>>>>> the same for dataprovider and datarequest.  I think is should be
>>>>> just a javascript class.
>>>>> Otherwise approved.
>>>>> On 2007-08-06, at 17:05 EDT, Henry Minsky wrote:
>>>>>> Change 20070806-hqm-8 by hqm at IBM-2E06404CB67 on 2007-08-06
>>>>>> 17:02:34 EDT
>>>>>>   in /cygdrive/c/users/hqm/openlaszlo/wafflecone
>>>>>>   for http://svn.openlaszlo.org/openlaszlo/branches/wafflecone
>>>>>> Summary: make base abstract LzDataProvider class
>>>>>> New Features:
>>>>>> This implements a common base class for LzDataProvider
>>>>>> implementations
>>>>>> to inherit from
>>>>>> Bugs Fixed:
>>>>>> Technical Reviewer: ptw (pending)
>>>>>> QA Reviewer: (pending)
>>>>>> Doc Reviewer: (pending)
>>>>>> Documentation:
>>>>>> Release Notes:
>>>>>> Details:
>>>>>> Tests:
>>>>>> Files:
>>>>>> M      WEB-INF/lps/lfc/kernel/swf/LzHTTPLoader.as
>>>>>> M      WEB-INF/lps/lfc/data/LzHTTPDataProvider.lzs
>>>>>> A      WEB-INF/lps/lfc/data/LzDataProvider.lzs
>>>>>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/
>>>>>> 20070806-hqm-8.tar
>>>>>> -- 
>>>>>> Henry Minsky
>>>>>> Software Architect
>>>>>> hminsky at laszlosystems.com
>>> 
>