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.
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).
`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.
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?
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? 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 -- even if that change is to the same state. A state
leading back to itself is fair game in state-machines, and it's fair
game in laszlo, i figure. I'm having a hard time summoning the
computer-science portion of this into well-worded paragraphs, so before
I go to that length, would the list like to comment on why there is a
need for independent state systems, i.e. why should i not conceptualize
all algorithms that laszlo development requires through the lens of all
attribute updates also being events? It's easier to teach and to read -
while maintaining what is a truism for me - preferably there should be
one clear way to promogulate state change through laszlo-land, and
attributes being used and equated with events does that. Would anyone
care to discuss somewhere it does not?
Looking forward to your next file. :)
Thank you, i'll be releasing my next file asap!
.j.
On 2009-11-14, at 01:05, jamesr wrote:
Good evening all,
Tonight i'm making available utils.lzx, after releasing the library.lzx file yesterday.
The utils file contains useful abstractions, dataset wrapper class (to work with an event
system that works with it to be introduced later), and functions wrapped inside of a
global id'd node, "Utils". It's a grab bag of very useful functions and is
expected to grow. Note that the functions I use for bring to front and send to back are
special -- they will actually modify the underlying subviews positons, not just the flash
layer! this is very important for drag and drop, especially.
Note that at this point, we still don't have anything that runs, and it is
pretty self explanatory (except for replicatedset, perhaps). I'm sticking with
one file a day, or less, if there are questions to type on about! The next
file, traits.lzx, will be the first place where each item will need examples.
You can follow updates at the url
http://code.google.com/p/viewablegroup/updates/list and check out the code tree
to play with. At any point, people interested in contributing may email me for
access; that's all premature of course.
I'm attending the green convention in SF this weekend I may wait a day before
getting traits.lzx in for review. The repo
(http://code.google.com/p/viewablegroup/updates/list) has been updated.
Best,
James.
Rami Ojares / AMG Oy wrote:
Hi James,
I will be following your achivements with interest.
This maillist is as good as any, but if you want to be precise I quess the
developer list would be more accurate considering that tou are presenting new
code possibly to be included in laslzo.
On the other hand the component code is written in laszlo so maybe it could be
considered as an example how to code in laszlo.
And thus the userlist seems the right choice.... who cares, right?
I have also been forced to code drag&drop stuff in laszlo (drag&drop is the
holy grail of web development :)
Your pseudocode looks very promising.
Two things that I personally need from dnd-system are
- custom mouse indicators (not the same as cursor but a visual presentation of
the dragged object)
And this needs to change in complex ways as the mouse keeps on being moved
while dragged.
- if the drag has been hovering over the same drag destination area for a
certain time then the destination should be notified about it
(eg. when dragging something on top of a folder in file explorer after some
time the folder opens)
So we can discuss how these could be implemented within your framework.
- rami
Update to the list about a new laszlo components framework, i'll be putting out
one source file a day until all of the files have been introduced and spoken
about. What follows is the first file to go up, the main file, library.lzx.
Tomorrow will be the first source file, in the order they appear below,
utils.lzx
Is there a more appropriate place to discuss this, or is it best that I post
here? I would like to start a discussion on several topics, over a period of
time.
As will always be the case, check out http://code.google.com/p/viewablegroup/
for the latest. The utils file listed below will have a liscense and comments
when posted later today.
.j.
(library.lzx showing the import structure of the framework follows)
<library>
<!-- includes we need -->
<include href="base/baseformitem.lzx"/>
<include href="base/multistatebutton.lzx"/>
<!-- resources -->
<include href="resources.lzx"/>
<!-- framework classes --> <include href="traits.lzx"/>
<include href="utils.lzx"/>
<include href="replicate.lzx"/>
<include href="layouts.lzx"/>
<include href="upload.lzx"/>
<!-- component hierarchies -->
<include href="ui.lzx"/>
<include href="reordering.lzx"/>
<include href="smoothScroll.lzx"/>
<include href="highlites.lzx"/>
<include href="toolbar.lzx"/>
</library>
---
jamesr wrote:
You can find the project, as yet unpopulated, at
http://code.google.com/p/viewablegroup/. Expect content before Nov 18th.
jamesr wrote:
Within the week i'll have that and the project hosted on google with licensing,
etc. and thus allow the list to have unfettered access to the base i'm using
for projects currently.
I don't use the CSS concept in this framework. I usually just specify skins for
a component, then override in subclasses. I see CSS as a higher layer then what
i'm operating on. It is also SWF9 ready.
There is a set of behaviors that underlie object creation and interaction
(including unique namespace mechanisms) that are essential to readable, modern,
and dependable GUI management. Traits in particular are defined as orthogonal
behaviors applied to a parent that modify or react to events or advertise new
methods and attributes, the same as the design manual for objective-C stated i
once possessed. They allow me to annotate nodes by behavior, greatly reducing
the semantic overhead for invocation of complex actions.
What follows is a good example of the framework. It is the entire code needed
to have drag and drop between arbitrary objects and it's representative of the
approach. It's just a code snippet, but i believe it is clear.
----
<canvas debug="true">
<!-- component hierarchies (ordered low-level to high-level)-->
<include href="../framework/utils.lzx"/>
<include href="../framework/traits.lzx"/>
<!-- this class will inherently search a given set of views -->
<class name="dragmetome" width="30" height="30" bgcolor="blue">
<multiclickable/>
<dragmatchable views="${classroot.parent.subviews}"/>
<handler name="ondragsent" args="target">
Debug.write("I (", this, ") was dragged onto", target);
target.setAttribute('bgcolor', this['bgcolor']);
</handler>
<handler name="ondragdropped" args="target">
Debug.write("I (", this, ") just got ", target, " dropped onto me");
</handler>
</class>
<view>
<simplelayout axis="y"/>
<dragmetome bgcolor="blue"/>
<dragmetome bgcolor="red"/>
<dragmetome bgcolor="green"/>
<dragmetome bgcolor="yellow"/>
<dragmetome bgcolor="brown"/>
<dragmetome bgcolor="purple"/>
<dragmetome bgcolor="green"/>
</view>
</canvas>
More soon,
j.
Raju Bitter wrote:
Yes, I'd love to see that as well. I'm hoping for fully runtime CSSable
components with a CSS based styling and skinning approach. That would give us a
chance to zoom components in DHTML runtime and SWFx runtime, making them much
more usable for mobile devices. Memory profile should be better as well, since
wouldn't have to load a large number of assets into the app.
But since nothing is perfect in life, I'd be happy to see any improvement on
the component side!
Raju
On Nov 12, 2009, at 2:09 AM, Max Carlson wrote:
Hi James,
I'd love to see what you've written! We're aware that the component class
model is aging and welcome collaboration from the community.
jamesr wrote:
Rami Ojares / AMG Oy wrote:
On Nov 11, 2009 1:19 AM, "Leonardo Mateo" <[email protected]
<mailto:[email protected]>> wrote:
That's not true, Flex is very powerful, thanks to ActionScript 3 and
is a COMPLETE MISTAKE thinking that you have to use it only for small
and flashy things.
I don't wish to dispute that. I meant that it probably has more GUIs and
templates to get you started quickly. The downside being vendor lock-in and
being at the mercy of your software provider.
When the push comes to shove your best and ONLY documentation is the source
code. That applies to both commercial and open source software as well as that
tiny and most precious piece of software you write yourself.
- Cheers
I would submit that open laszlo is an easier to learn and manage language. I
believe in the laszlo model, and choose it because of that belief. However,
several key concepts are missing from the download you get from open laszlo
itself. Things like drag and drop and traits have been poorly defined if at
all. The components hierarchy is aging. I've written a complementary and more
modern hierarchy, one which i'd be happy to share with the community, if it can
tolerate incremental improvement in the documentation and examples.
Laszlo is a view based language, like cocoa. It has not been adequately
utilized in the areas in which it excels most; this is the root problem of the
laszlo community at present, as i see it. The premise is sound.
- james
--
Regards,
Max Carlson
OpenLaszlo.org
