I 100% agree with this. We are doing a similar but adhoc method, but your solution seems much better.
Regards Rajeev J Sebastian On 30-Dec-2010, at 10:11 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/Behavior.OverText.js > > Example usage: > > https://github.com/anutron/more-behaviors/blob/master/Tests/Behaviors/Behavior.OverText.html > > 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/Behavior.Resizable.js > 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 — > >
