Why limit it? =P
On Thu, Sep 15, 2011 at 1:11 PM, Aaron Newton <[email protected]> wrote: > 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 >>> >>> >>> > -- http://lonestarlightandsound.com/
