Hi James,
I glanced quickly over the utils and for now I have this to say.
Your framework seems to touch on many areas like
- mouse and dragging
- replication and other dataset related features
- behaviors and traits
(some abstract things that still need some explaining at least for me.
(I think traits you already explained as 'orthogonal behaviors applied
to a parent that modify or react to events or advertise new methods and
attributes'
which does sound like a good laszlo coding pattern)
- generic utility methods
While this is all good and well I quess it would be easier to discuss if
one feature could be separated from each other and introduced separately.
Now there is the danger that too much is introduced in one big mouthful
and it is hard to discuss for example mouse and dragging related
features separately.
Also it would be better for the components if they could work on their
own without the rest of the framework.
This way the code would not be so entangled.
And then the combining of the features could be done by the software
developer.
I am interested in commenting the mouse related stuff but I would not
want to comment about other stuff like replicating or some utility methods.
What do you think?
- rami
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
