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. 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. `copyArray` can be written very efficiently: `<array>.concat()` Maybe you could file a bug about `bringToFront` not reordering subviews if that is important? 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? In `now`, if your purpose is to send events, why not actually send events (using `sendEvent`), rather than trying to outwit `setAttribute`? Looking forward to your next file. :) 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 >>>>>> >>
