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 <[EMAIL PROTECTED]> > Datum: Mon, 6 Aug 2007 22:38:00 -0400 > An: Pablo Kang <[EMAIL PROTECTED]> > Cc: Henry Q Minsky <[EMAIL PROTECTED]>, Laszlo-dev bug reporting > <[email protected]>, P T Withington <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED] 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 >>>>>> [EMAIL PROTECTED] >>> >
