I follow you 100%. Going to think about it some more in a few hours (driving home in a about 10 mins) .. and decide my next move.
On Oct 11, 2:00 am, Aaron Newton <[email protected]> wrote: > > 1) > > The "gridRendered" event is not picked up (in Preview filter) when > > there is no element in the dom with the data-behavior="Preview" > > attribute. (when the filter hasn't run) > > In assumed the filter Preview was registered and globally > > "listening" (to catch the fired event) even if the Preview filter has > > not been actively used yet (by some already declared element in the > > dom). > > So, to test it I added a dummy div to the dom (not associated to the > > list that is turned into the grid) with the data-behavior="Preview" > > attribute, which is silly of course... > > What's wrong with my thinking process? > > Behavior filters are rendered in DOM order (so containers with filters have > their filters applied before their children, and siblings with filters have > theirs applied first child, then second, and so on). Filters are also > applied in the ordered they are listed, so if you have data-behavior="A B" > it will render A and then B. The biggest reason that the rule is that > filters can't know about each other is that the user of the filter shouldn't > have to know that A comes before B (or whatever) and it gets even more > complicated the more filters you add. > > When you give an element a filter property, that filter's setup method is > invoked (the function you define; there's also a long-form version of a > filter that's an object with that function defined as the "setup" property). > Anyway, that function is never invoked if there is no element with that > filter. So if you don't have an element with data-behavior="Preview" your > function which adds the event listener will never be invoked. Make sense? > > > > > 2) > > The Preview class (and thus the Behavior filter) is setup for one 1 > > element basically. If I add data-behavior="Preview" to an element the > > filter is called and the class is instantiated. > > But in the code above I abuse the "gridRendered" event to call a > > preview() method on an array of elements I select with a css selector > > on the grid container (basically: all childs except empty cells). > > (the preview method call does: return new Preview(this, options) - > > pretty straightforward). > > This is of course wrong: I should not call the Element method > > preview() on multiple elements in a filter created to manage 1 > > element. > > How should I "get this right"? > > It seems to me that the "Preview" class is not a behavior filter. It's not > something in the DOM that gets decorated. Rather, it's something that gets > instantiated by your Grid class. Because you don't want your grid to have > knowledge of your preview class (instead opting to connect the two together > with events, which I think is appropriate), I see three options for you: > > 1. Create a super class that knows about Grid and Preview (GridPreview). > Create a filter for this. > 2. Create a behavior that has the event hooks into the Grid that creates > previews (a behavior filter called GridPreview that has onComplete: > function(){ new Preview...} in the invocation of the grid class). > 3. Have only one behavior filter (Grid) but an option that turns on > previews for the grid that, when true, adds these event hooks. > > For filters to work right, they each have to do a thing on their own. Use > even arbitration when they need to coordinate their behavior. Thus a Preview > class that does it's own thing and works even if the Grid isn't there and > vice versa. Your DOM is decorated with BOTH of these things and the event > arbitration exists only to deal with the event that they are both in use on > the same DOM tree. > > -a
