On 2009-11-14, at 21:22, jamesr wrote:
Hello PT, good to have you to speak with, along with the rest of the list! I'm
happy to get questions this early, since you and Rami caught the hints
utils.lzx makes about the rest of the framework. I'll respond to Rami after
this. I've replied inline to your questions, below.
P T Withington wrote:
Thanks for making this available.
Some thoughts:
`shift` is definitely going to be faster than `reverse/push/reverse`.
I'm pretty sure there is a built-in `isMouseOver` which also worries about
visibility and clipping. If you stick with your version, remember that
mouse-coords are 0-based, so comparison with width/height should be exclusive.
I would use it if i knew about it. I think there is; i didn't "trust" it since
i (being lazy in somethings) couldn't easily find the source that comprises it to check.
I appreciate the 0-base hint, that will be fixed.
This is supposed to be the beauty of open source. That you _can_ find the
source and the source is the ultimate documentation.
http://labs.openlaszlo.org/trunk-nightly/docs/reference/lz.view.html#LzView.prototype.isMouseOver
http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/views/LaszloView.lzs
If you are having trouble overriding in swf9, be sure you match the function's
signature. All public LFC API's should be overrideable. If you find one that
is not, please file a bug.
In this case, i wanted to have the same method name with a different signature. I wanted
to adveritse a Utils.animate() method to be used in all animation scenarios, but it takes
less/different information then the "real" animate, thus i was cordoned into
changing the name as a last recourse. I found that out in the conversion to SWF9, and
wouldn't mind knowing if it's possible to do what i want (same method name, different
signature).
No, you cannot override a function with a different signature. AS3 is not C++. Unlike
C++, most other O-O languages operate this way: a function signature defines a type and
method dispatch is type-based. You can approximate overloading by using untyped
arguments and the "rest" argument `...`.
`copyArray` can be written very efficiently: `<array>.concat()`
noted to-be-fixed, thanks! some of this is from older projects, given, i'm very
happy to include all things like this since a goal is to use all the most
up-to-date patterns.
Maybe you could file a bug about `bringToFront` not reordering subviews if that
is important?
It is very important. Imagine i am trying to determine which view is on top of
another in absolute terms, so that i can decide in what order to evaluate those
views for whether the mouse is over it, ensuring proper z-depth-normal
responses. This runs the drag trait's entire ability, and it was something i
had to crack to enable it.
<view> has a method `getDepthList` that returns the subviews in depth-order,
but if it is important to maintain the order at all times, again, why not file an
improvement request?
The built-in `containsPt` includes something like your `absVisible` -- views
that are not visible can't contain a point. Perhaps it should be broken out as
a separate API? File an improvement request?
Stated another way, I think my issue is actually having these functions at-hand
and extendable, and illustrated somewhere i could find them. For me it goes
back to not being able to find javascript implemenations of laszlo functions to
learn from and feel confident about. I think that these functions should live
in user-space, so to speak, instead of being part of the underlying language;
ymmv/discuss?
The source is open for all to see and there is no restriction on extending the LFC core
classes. I'm not sure what you mean by "should live in user space"? Please,
if you see a need, file an improvement request. One of the points of open source is that
we all help each other improve the system we share.
In `now`, if your purpose is to send events, why not actually send events
(using `sendEvent`), rather than trying to outwit `setAttribute`?
There are a few reasons, pardon me if don't find them all in this email; i'm
recreating the line of reasoning that was gone through developing it. I believe
the base problem is that i cannot declare events that will respond
just-like-attributes (e.g. handlers are recognized and set up for use)
dynamically. In this sense, setAttribute(x, v?) will always cause handlers to
fire, while sendEvent will only work if there is indeed an event declared. Am I
wrong?
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:
<attribute name="myAttribute" ... />
to declare a property of a class or instance before you can write
`setAttribute('myAttribute', ...)` you say:
<event name="myEvent" />
to declare an event of a class or instance before you can write
`myEvent.sendEvent(...)`.
Ah, yes i remember, there is a second, more important reason too. It is based
in computer science, but may be subject to opinion. I have a strong one in this
regard.
I would like to show that the linkage between "attribute-event-handler" is not casual and
that events, while perhaps being a "glue" to make the connection between attributes and
handlers work, do not have a place in user-space code. I would like to show that they override the
already-abstracted pattern that attribute-handler provides and are redundant to use, i.e. they work
against a fundamental pattern in Laszlo. It is my belief that the event subsystem, while perhaps
necessary for the formulation of the attribute-event-handler linkage, should remain behind the
purer abstraction that the attribute-handler linkage provides. A further conversation on this topic
involves discussions of state and the meaning of state in Laszlo. There are also developments in
replication that obviate the need to ignore duplicate states being passed around. Here's a little
more:
I've written my own "laszlo" runtime - not that i can call it that, but see
http://code.google.com/p/pyroglyph - and what i mean to illustrate is that is that i've taken the
laszlo philosophy and - IMHO - standardized it around pseudo-code concepts that all
"laszlo-like" runtimes could/should support. The fallout from that potent learning
experience is that having different systems that perform the same asic function - causing handlers
to run - is unnecessary and doesn't enable additional features. In python, with it's __setattr__
and __getattr__ hooks, you have no need to use setAttribute -- all such attribute changes on a
class fire handlers if there are any (although there is a standard way to set it without calling
handlers if speed is important there). This worked very well - so well in fact that i did not
recreate the event system in my own runtime as it was never needed. In essence, every time a
declared attribute is updated, that is synonymous with a state change !
