Um. Thanks? Do you mean the code? Or that email? On Thu, Sep 15, 2011 at 10:35 AM, Lee <[email protected]> wrote:
> Aaron - superb writing! > > > On 15/09/2011 17:53, Aaron Newton wrote: > >> What you're looking for is an event arbitrator. ... which is what Behavior >> is (and Delegator, too). >> >> You write your Classes with event hooks like normal (onComplete, onLoad, >> onShow, onHide, etc). And then you fire events against Behavior that your >> filters can look for. Here's an example: >> >> https://github.com/anutron/**more-behaviors/blob/master/** >> Source/Forms/Behavior.**OverText.js#L27<https://github.com/anutron/more-behaviors/blob/master/Source/Forms/Behavior.OverText.js#L27> >> >> This line adds an event to the Behavior instance that's invoking the >> filter. When that behavior instance fires the event "layout:display" it >> invokes that callback. >> >> Or here, a delegator that fires events when it updates the DOM: >> >> https://github.com/anutron/**more-behaviors/blob/master/** >> Source/Delegators/Delegator.**Ajax.js#L58<https://github.com/anutron/more-behaviors/blob/master/Source/Delegators/Delegator.Ajax.js#L58> >> >> This allows two filters to pass messages to each other (or the classes >> they instantiate to do so) by using the addEvent/fireEvent methods on the >> api. So if you have Class A that fires and event that Class B needs to know >> about, your filter, which creates those instances, can do so, even if the >> other doesn't exist. >> >> >> >> On Thu, Sep 15, 2011 at 7:09 AM, Eric Patrick <[email protected]<mailto: >> [email protected]>> wrote: >> >> Thanks for the feedback. >> >> I will be happy to release them once I've kicked the tires. Trying to >> make them really reusable begets another question with respect to >> event delegation. >> >> I have a series of very specific classes (Contact, Message, >> Attachment, etc) that represent business objects and communicate via >> web services. Typically these classes have a target DOM element they >> use to display their content. >> >> I then have generic behavior to field things like pagination of a list >> of Contacts (or Messages, or Attachments, etc.). >> >> When a pagination event fires, I essentially want my Contact class to >> listen for it. >> >> Option 1: create an custom event on Element >> >> Create a custom event on Element (Element.paginate, based on the click >> handler), and have the Contact's DOM element listen for the paginate >> event. >> >> However, that strikes me as "resource intensive". I may well >> misunderstand, but the Element.paginate's condition function would be >> evaluated on every mouse click on every element. Given the complexity >> of some of my pages, I'm worried about performance. >> >> I had hoped something like this would work instead: >> >> http://jsfiddle.net/kBGLQ/ >> >> Option 2: >> >> In my Paginate behavior, I call a global function to find and return >> the containing class (Contact), and fire a custom event on the >> class. >> >> This works, and strikes me a reasonably efficient. However, it ties my >> Paginate behavior to the existence of very specific classes. >> >> See http://jsfiddle.net/wB3n7/1/ >> >> Option 3: >> >> I suspect I'm missing a more generic, equally efficient option. >> >> Thanks as always, >> >> Eric >> >> On Sep 14, 2:32 pm, Aaron Newton <[email protected] >> <mailto:[email protected]>> wrote: >> > Hi Eric, >> > >> > Thus far I haven't worried about namespacing filters. Remember >> that you >> > control which ones are loaded and which ones are in effect. Behavior >> > instances can have local filters that override globals, etc. >> > >> > If, however, you want to be safe, you could use any of the >> examples below. I >> > don't know if I have a preference. >> > >> > Are you going to release these behaviors? I'd love to see more >> people >> > publishing them... >> > >> > >> > >> > >> > >> > >> > >> > On Wed, Sep 14, 2011 at 10:09 AM, Eric Patrick >> <[email protected] <mailto:[email protected]>> wrote: >> > > Thanks for the Behavior / BehaviorAPI Aaron; it's great to >> work with! >> > >> > > I am developing a bunch of behaviors centered on dealing with >> AJAX- >> > > loaded data grids: >> > >> > > - Paginate: handles creation of DOM elements for a pagination row, >> > > raising an event when a page or display size is changed >> > > - OrderBy: handles making column headers sortable >> > > - Filter: handles modification of JSON from a form to >> re-submit via >> > > Request.HTML or Request.JSON >> > >> > > It occurs to me others may do something similar. Any thoughts or >> > > advice on "name spacing" behaviors? >> > >> > > <div data-behaviors="Paginate, Filter"/> >> > >> > > vs. my name space (mns) >> > >> > > <div data-behaviors="mns.Paginate, mns.Filter"/> >> > >> > > vs. >> > >> > > <div data-behaviors="mns-Paginate, mns-Filter"/> >> > >> > > vs. >> > >> > > <div data-behaviors="mnsPaginate, mnsFilter"/> >> > >> > > Thanks in advance, >> > >> > > Eric >> >> >>
