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]
