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 —
