@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]> 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]> 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 >> > >> > Example filter: >> > >> > https://github.com/anutron/more-behaviors/blob/master/Source/Forms/Be. >> .. >> > >> > Example usage: >> > >> > 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... >> > 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 >> > >> > > — Thomas Aylott – SubtleGradient – MooTools – Cloudera — >> > >
