Just noticed the docs. Will read them! On Fri, Dec 31, 2010 at 2:59 PM, אריה גלזר <[email protected]> wrote:
> @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 > > -- Arieh Glazer אריה גלזר 052-5348-561 http://www.arieh.co.il http://www.link-wd.co.il
