Eric has the general idea correct here. The important rule to never violate is to ensure that no filter depends on another. If you DO have a dependency - where one filter makes no sense without another either create a new filter (that creates instances of both your classes) or a filter plugin.
When to choose one over the other? The event arbitration method is cleaner in that other filters that you or someone else writes later can implement it (instead of writing a plugin for every single new thing). But sometimes you have something truly esoteric that makes zero sense to use arbitration. Plugins are mostly intended for creating specialized implementations for your environment. For example, let's say you want to use the Form.Validator plugin but you want to add some additional logic in your app. So you write a plugin for your app's implementation of that filter. Anyway, back to your actual use case. Here's what I'd write: 1) I'd not put the image information as a filter property but rather actually put the images inline. Part of Behavior's impetus is to have regular HTML documents that work without the JavaScript. So I'd have my list with images and then style them in CSS. Hide the text and put them in a grid or whatever. I'd put that grid in an overflown element so that the user can scroll through them. 2) I'd write a class that turns overflown elements into a paginated set. You could configure it with explicit dimensions or have it read the sizes of the elements and guess how to paginate. It then wraps up your content and puts the page controls in place. This way it degrades well and the HTML isn't overly complicated. It's a list with some images. If you turn off the pagination, it still looks great. On Sun, Oct 9, 2011 at 2:23 PM, Eric Patrick <[email protected]> wrote: > I'm not entirely sure this addresses your question, but it sounds > similar to an issue Aaron assisted me with. > > I will assume that you have: > > - a Class 'GridView' > - a Class 'GridPreview' > - a Behavior 'Grid' > - a Behavior 'Preview' > > The theory is to use the Behavior API as an event arbitrator between > your GridView and GridPreview classes, like this: > > Behavior.addGlobalFilter('Grid', function(el, api) { > // create your GridView class > var myGridView = ... > myGridView.addEvent('complete', function() { > api.fireEvent('gridRendered', {}); // I'm passing empty args, but > you may need to pass something substantial > }) > }); > > Behavior.addGlobalFilter('Preview', function(el, api) { > // create your GridPreview class > var myGridPreview = ... > api.addEvent('gridRendered', function(args) { > myGridPreview.preview(args) > }); > }); > > The pattern above has worked well for me working with classes that > deal with fetching server-side data and a pagination class. > > Regards, > > Eric > > On Oct 9, 7:18 am, Rolf Langenhuijzen <[email protected]> wrote: > > (Hi Aaron,) > > > > Apologies for this non-focused subject, but I couldn't think of a > > shorter to the point one.. > > > > Here's my case slightly modified/simplyfied: > > 1. I have a simple list with items. These items are just text, like > > names of people. I also add a data-image="my-image.jpg" to the list > > element. > > 2. With a class I turn this into a grid view and it fires an > > onComplete. In the onComplete I trigger a pagination class that turns > > the grid in X pages in a smaller viewport and some controls. > > 3. I use the onComplete from the paginate class to trigger a final > > class (preview) that enriches the grid with images using the data- > > attribute. > > > > Let's cut out 2 for now (the pagination part). > > > > When I use Behavior to create the grid. How should I use the complete > > event to trigger the 'preview' class for the elements in the grid? > > The preview class is dependent on the grid.. if there's no grid, there > > are no images. > > > > Rolf >
