Thanks for the responses! Didn't know it was as easy as demonstated with the event arbitration method. I'll try and see how it works.
Some specific response to Aaron's thoughts: 1) I don't have images inline because in this case it wouldn't work, plus it could be too many images to load (or create dynamically). I simplified the case description. The actual grid is created with options that can be set per element (eg. a colspan:2 rowspan:2 setting). 2) The pagination class takes a default "max-rows-to-show" option into consideration and hides other rows. But, depending if an element spans more rows that what is visible by default it will have to expand the viewport, which in turn affects the page controls :) - I'm working on that with some prototype hack 'n slash code. 3) Depending on what is visible I would trigger the preview class and it would replace the content of grid elements with images (and in my case it should load some webfonts). Using Class.Occlude this is done only once per element. All classes could be used on their own (though atm the paginate class is a bit bound to how the grid is created, but that's because i'm prototyping) If there's no javascript you still have a list with all items/links - no problemo. On Oct 10, 3:13 am, Aaron Newton <[email protected]> wrote: > 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
