[development] behaviors context

[Matt]

On Fri, May 29, 2009 at 2:59 PM, Daniel F. Kudwien
<news at unleashedmind.com> wrote:

> Now, you do the math:
>
> 10 ms * ~20+ behaviors = 200+ ms

Actually, I was figuring 10ms for LOTS of behaviors. Not PER behavior.
A selector should clearly take well under 10ms. Any additional
overhead for a behavior is going to be the same regardless of whether
you use context or selectors.

>> There are two patterns in Drupal JS to "prevent" the same
>> behavior from processing the same data twice. One is the
>> :not(processed-X) pattern, which seems to be pretty reliable,
>> and is pretty much entirely in the hands of the author of the
>> behavior (barring a misanthrope who decides to remove your
>> processed classes).
>
> ...which equally cannot solve your trivial zebra-striping table row example.
> Once your table :is(.processed), your behavior can't (shouldn't) process it
> again.

Oh, come on... you wouldn't drop a zebra stripe processed class on the
table, would you? You'd drop it on the row. And if you found rows in a
table without striping, you'd re-process the entire table.

The problem occurs only when you assume the context is passing
sufficient information for your behavior. The context may in fact be
providing less information than you need, and you are at the liberty
of whatever called attachBehavior() in the first place (which may not
be something in core -- there's no way to tell). Consequently, it's
better to rely on the document itself, not just the context.

Matt

-- 
http://technosophos.com
http://querypath.org