I follow your thoughts.. totally agree. Especially with css +
transitions + pseudo elements a lot can be done right.
Have to check benchmark.js!
With regard to the Behavior event arbitration method...I'm not getting
it.. or at least, not for my current case:
Behavior.addGlobalFilter('Grid', function(element, api){
var grid = new Grid(element, ...);
grid.addEvent('complete', function(){ api.fireEvent('gridRendered',
element); });
grid.make();
return grid;
});
Behavior.addGlobalFilter('Preview', function(element, api){
var preview = new Preview(element, ...);
api.addEvent('gridRendered', function(container){
console.log('gridRendered', container);
container.getElements('some-selector').preview();
});
return preview;
});
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?
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"?
Should I just create a filter that is called PreviewMany which runs my
Element method preview() on a collection of elements? and
And then I should add this behavior to my list element also: <ul data-
behavior="Grid PreviewMany" ...>... </ul> else it's not listening to
my event firing........
It's starting to get confusing, no? ;)
anyway- tia... 1.48am here now.. time to zzz
On Oct 10, 5:07 pm, Aaron Newton <[email protected]> wrote:
> > 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).
>
> That's cool. My point mainly is that I often find myself wanting to make
> things work with JavaScript that browsers are actually really good at.
> Browsers are pretty awesome at dealing with a lot of images, for example.
> Whenever you can solve the problem with HTML, do it. Whenever you can solve
> it with HTML + CSS, do it. When you can't, there's JavaScript.
>
> One thing you might also consider is spending a little time with
> Benchmark.js It'll tell you what your application really costs. If you are
> using Behavior, you get benchmarks and unit tests almost for free. Look at
> the tests in More-Behaviors or in Bootstrap. To run them, check
> outhttps://github.com/anutron/mootools-development/tree/clientcide(quite
> specifically the clientcide configuration).
>
> > 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.
>
> Optimization suggestion: if you have a lot of rows, hide them all and have
> your code show the first batch rather than the other way around.
>
> > 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.
>
> Behavior does this for you. When you do myBehavior.apply(element) it applies
> to that element and its children, but if you did it again, it wouldn't
> invoke the filters again. It would do the DOM search for data-behavior
> elements again, loop through them, and see that they've already been set up.
> If you did myBehavior.cleanup(element) and THEN called apply again, it would
> invoke the filters again, but otherwise not.
>
> Also, you can *greatly* increase your startup time for filters that only
> have actions when you mouseover them or click them or whatever by using the
> delayUntil option. Tips, for example, need not be instantiated if the user
> never mouses over them.
>
> > 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.
>
> Nice.
