I think I get what you're writing about. It makes sense when you're behavior affects, say, all elements of a certain class. And you can update the class after the behavior acts. But in my case, I need to operate over all elements. So to do what you're talking about I'd need to add classes all over the place. Specifically, I'm working with Facebook Connect. And I need to tell facebook's javascript to parse any markup added to a page. They provide methods to do this, http://wiki.developers.facebook.com/index.php/JS_API_T_FB.XFBML.Host. One method parses the whole dom tree, another limits the parse to specific elements. For performance reasons I prefer to use the more limited method, but I'll resort to the other if I really have to. -Dave On Fri, 29 May 2009 14:34 -0500, "Matt" <matt@aleph-null.tv> wrote:
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).