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]> 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 — > >
