Dynamically creating listeners (on a parent) is nescessary for the
traits pattern i currently use, and there is no substitute; either it's
done this way, or the actual laszlo traits subsystem is revived (yay! i
had this in pyroglyph) where any number of classes can be specified,
comma seperated, in a traits attribute where each of the children of the
class (not any variables on the trait-class-source) are added to the
traited class. We don't have this yet, so in that light i must mention
that it is not a case of bad design. Dynamically creating handlers and
listeners is essential in using laszlo correctly, as i see it, and
without it the benefits of working in javascript is negated. I expect
that kind of strictness in Objective-C, for instance, but i want to be
better then that; i'd like to see all dynamic opportunites used when
they improve upon how laszlo can be code-minimized and reusable. I'm
working diligently to get the traits file to where i want it to be
(there is just one little issue i want to explore about whenables and
watchables) and then i'll have case studies to share and resolve with
"you" (the list)
Thanks for the links into the LFC btw!
P T Withington wrote:
On 2009-11-15, at 13:41, jamesr wrote:
Good Morning, I pulled two things out of the response that i wanted to single
out and discuss.
*snip*
You can't set an attribute that does not exist, so you have to declare the
attribute first. Just as you would have to declare the event first. The same
way you say:
Actually, yes i can, and handlers fire too; this is a behavior i have always assumed,
relied on, and built into the patterns i use. If i use setAttribute(a, b), the handlers
for the event a will fire even if i haven't declared "a". Have I misunderstood
you?
If a tree falls in the forest and no one is around, does it make a noise?
Yes, due to the dynamic nature of LZX, you can set an attribute that has not
been declared on an instance. But I have to wonder: if you have not declared
the attribute, how will anyone know to listen? It's just good programming
practice to declare your attributes.
and
*snip*
If you want the latter behavior, you should be using events. That is their
contract.
It is still the case of having a redundant pattern, not just speaking about the
constraint system. I would submit that the purpose of events and attributes are
intertwined and, apart from momentum, i don't see why you would wire the system
to have any care about it.
If all you have is a hammer, everything looks like a nail.
There is enough flexibility in the constraint system that you can make it
function as an event system, but as you have discovered, you have to subvert it
by setting a new value each time in order to force it to send an event.
We must be missing each other's point here. If I want an event, I would send
an event, not use a constraint.
The entirety of my traits file, and other patterns i like, depend on the above, so i'd like to be
clear as we go on; i venture that the next file to share will give us examples to speak of and
rewrite "my way" and the "other way" and see why i've figured there is such a
big difference.
Looking forward to it.
