@Aaron - this is very very cool. Do you plan on adding some docs for use cases and extended examples (for example - what to do with the passes events object etc)
I would love to see how this can be used (obviously, since this is integrated with ART, it will probably require some ART docs as well, but still - I would love to see how this should be used in an app). I really see myself using this btw - are you planning to move this to 1.3? On Fri, Dec 31, 2010 at 2:27 AM, Aaron Newton <[email protected]> wrote: > Something destroys it. It doesn't happen magically. In the case of Hue, > it's various Ajax calls that destroy and replace UI elements. > > Sorry for any typos. Tiny buttons, big thumbs... > > On Dec 30, 2010, at 2:46 PM, Arian Stolwijk <[email protected]> wrote: > > @Aaron: how do you know when an element is destroyed for garbage > collection? > > On Thu, Dec 30, 2010 at 11:22 PM, Aaron Newton < <[email protected]> > [email protected]> wrote: > >> First, it's not inconceivable that the entire app could be expressed w/ >> HTML. Your argument that the HTML would be littered with all these >> annotations is accurate, but the flip side is that the app works w/o >> JavaScript at all which makes for some nicer debugging >> and maintenance options. Nearly all of Hue works in "Web 1.0" mode. Among >> other things it means that if, say, we had to support a UI for blind people >> who use screen readers... well, guess what, we already have one. >> >> It also forces you to separate your interaction (js) from the data (html) >> and the layout (css). This compartmentalization pays a lot of dividends, not >> the least of which is that your code is easier to maintain and test. >> >> As for altering the behaviors for custom actions, there are two ways that >> Behavior allows for this. >> >> 1) You can overwrite a filter; just declare a version locally that is >> different. Behavior has a concept of "global filters" - aka, the "Accordion" >> filter just creates a new instance of Fx.Accordion. This filter is added as >> a "global" filter so all instances of Behavior have it (if you include >> Behavior.Accordion.js in your environment). But instances of Behavior can >> also have "local" filters, filters that are only on the instance. So if you >> have a widget called "Foo" and each instance of Foo has a behavior instance, >> you can write a filter that only applies to them and not globally. This way >> you can introduce custom behaviors. >> >> 2) Behavior filters can have "plugins". It's a rule of my implementation >> that filters can't rely upon or even be aware of each other. Because I can >> do this: >> >> <form data-filters="FormRequest, FormValidator, X, Y, Z, etc"> >> >> It's possible for numerous filters to be invoked on a single element and >> in any order (they are invoked in the order declared). So FormValidator >> can't rely on always being used with or invoked before or after the >> FormRequest filter. Additionally, your example asked what you would do if >> you wanted to add some additional behavior like a Roar-like notification. >> Behavior allows you to do this with plugins. Plugins are always run after >> the filter they augment, so unlike regular filters they are assured both an >> order and that the thing they require is present. >> >> Thus you could do this: >> >> Behavior.addGlobalPlugin('FormRequest', 'FormRequestWithRoar', >> function(element, behaviorAPI){ >> >> var fRequest = element.retrieve('FormRequest'); >> fRequest.addEvent('complete', function(){ >> new Roar('whatever'); >> }); >> >> }); >> >> Now all elements that have the "FormRequest" filter will also invoke the >> method defined as a plugin for it. >> >> -a >> >> >> On Thu, Dec 30, 2010 at 1:40 PM, Rolf -nl < <[email protected]> >> [email protected]> wrote: >> >>> I was wondering Aaron how/if you use this for "exceptions" where you >>> need extra functionality after let's say a Form.Request. For example >>> you not only need to update an element, but you also want to activate >>> a popup or a roar-like notifier. Or maybe you want to send a new >>> sorted list to the server to save it, but this doesn't apply for all >>> sortable lists (maybe some are just sortable for visual aid). >>> >>> With Form.Validator you store validator on the element and you >>> retrieve it with setOptions to make use of the onComplete.. but then >>> every class should store itself on the element to have such >>> functionality, or what am I missing? >>> >>> >>> On Dec 30, 5:41 pm, Aaron Newton <[email protected]> wrote: >>> > For some indication of what we use in Hue (Cloudera's Desktop UI), >>> here's >>> > the Behavior class I authored for that purpose: >>> > >>> > <https://github.com/anutron/behavior> >>> https://github.com/anutron/behavior >>> > >>> > Example filter: >>> > >>> > >>> <https://github.com/anutron/more-behaviors/blob/master/Source/Forms/Be.> >>> https://github.com/anutron/more-behaviors/blob/master/Source/Forms/Be... >>> > >>> > Example usage: >>> > >>> > >>> <https://github.com/anutron/more-behaviors/blob/master/Tests/Behaviors.> >>> https://github.com/anutron/more-behaviors/blob/master/Tests/Behaviors... >>> > >>> > I'm not enamored with the declarative conventions in use, but they work >>> > well. Essentially: >>> > >>> > - there's only one selector ever run to get all the elements that >>> need to >>> > be constructed ([data-filters]), which is better than just using >>> class names >>> > because every time you add a new filter your app gets slower. >>> > - elements can have numerous filters of course (FormValidator, >>> > FormRequest) >>> > - properties for individual filters are arbitrary data-* properties. >>> For >>> > example, here's a filter for Drag.Resize: >>> > >>> > >>> > <https://github.com/anutron/more-behaviors/blob/master/Source/Drag/Beh.> >>> https://github.com/anutron/more-behaviors/blob/master/Source/Drag/Beh... >>> > it uses *data-resize-handle* and *data-resize-modifiers* to pass >>> along >>> > values to the drag instance. Each filter can arbitrarily choose what >>> > arguments it'll fetch from the element properties this way. There's >>> a >>> > potential for name collision obviously. Note that these arguments >>> are often >>> > used *by the filter* and not necessarily by the class the filter >>> invokes. >>> > >>> > We could drop the data-* which makes the pattern a little nicer looking >>> but >>> > less valid. We could come up with a convention for declaring arguments >>> that >>> > is a little less arbitrary... >>> > >>> > FWIW though, I love developing this way. I don't have hardly any >>> > "application" code but rather all these patterns that are much easier >>> to >>> > reuse... >>> > >>> > On Thu, Dec 30, 2010 at 6:52 AM, Thomas Aylott < >>> [email protected]>wrote: >>> > >>> > >>> > >>> > > Ahoy, >>> > > Dojo, Apple iAds as well as Adobe Flex and a million others >>> > > have created simple declarative APIs that you can use in your HTML. >>> > > This lets you basically replace your app.js or page.js code and get >>> rid of >>> > > the massive domredy scripts you see people use all the time. >>> > >>> > > Instead there’s a single parser that runs on domready that looks for >>> > > elements with special attributes and then instantiates all your >>> classes for >>> > > you based on the attributes declared in your HTML. >>> > >>> > > The goal is to allow your JS-n00b co-workers to ‘code’ without >>> screwing up >>> > > your lovely JS and making massive rats nests that you’ll have to >>> clean up >>> > > later. There are other goals too ofcourse. >>> > >>> > > So… What syntax do you guys like? >>> > > If you have other suggestions please fork and add! >>> > >>> > > <https://gist.github.com/759332>https://gist.github.com/759332 >>> > >>> > > — Thomas Aylott – SubtleGradient – MooTools – Cloudera — >>> >> >> > -- Arieh Glazer אריה גלזר 052-5348-561 http://www.arieh.co.il http://www.link-wd.co.il
