Behavior: order independency and keeping it that way (in combination with changing the dom)

[Rolf-nl]

Just a tip to everyone:
It is said before and clearly stated in the docs: filters do not have
any guarantee that they will be invoked in any given order.
Everyone should be aware of the fact that when a filter is invoked it
is using the current dom. If filter A changes the dom, filter B will
work with the changed dom and not your initial html markup. This seems
pretty obvious when you read this, though keep reminding yourself
about it when working with filters :)

So here is a use case and a question about the correct approach.

I have two classes that I use as behavior filters:
One is an application specific class that can be applied to a select
element. Among other things it will handle the change event but more
importantly it will add one or more extra options to the select which
in turn when selected invoke specific methods in the class.

Two is basically a design/style class for select elements that turns
them into a css-styleable list. It hides the original select, creates
a div with ul & li elements, adds keyboard control etc. This could be
as fancy as you want it to be. When you pick an option in the styled
select it will fire the change event on the original select element.

Using them both in the old days I would probably instantiate classOne
that fires a "ready" event and then onReady instantiate classTwo that
re-styles the changed select.

Now with Behavior they should work order independantly no matter what.
But if I declare classTwo first for the styling and that classOne I
would not see the extra added options in my just-created-styled-select-
replacer.

Possible solutions I think are:
1 - Create a small extra class for this use case that is like a
controller class, the one that glues the two classes together. This
new class is basically the old way of doing it and this new class
becomes the behavior filter that is declared in element (data-
behavior="GlueClassForClassOneClassTwo").
2 - When classOne adds an option to the select it should fire some
event update event that I can pick up and let the world know:
api.fireEvent('classOneSelectUpdated'); I can listen for this event in
the other filter classTwo that styles the select which calls some
rebuild methods to update the styled-select-replacer.

I would vote for solution 2 for cleaner code. I can easily fire events
from my own classes wherever I want, but the downside is that when
your using 3rd party classes out of the box and it is missing this
stuff you would have to check and update all code to make sure it
works all the time (so if an update comes out you have to check it
etc. etc.).

Does this all make sense?

/rant

;)

[Aaron Newton]

1 - Create a small extra class for this use case that is like a
controller class, the one that glues the two classes together. This
new class is basically the old way of doing it and this new class
becomes the behavior filter that is declared in element (data-
behavior="GlueClassForClassOneClassTwo").
2 - When classOne adds an option to the select it should fire some
event update event that I can pick up and let the world know:
api.fireEvent('classOneSelectUpdated'); I can listen for this event in
the other filter classTwo that styles the select which calls some
rebuild methods to update the styled-select-replacer.

I think either of these are valid. I think I'd also be inclined to use option #2. 

[Rolf-nl]

Ok, thanks, sometimes you just need someone else to confirm what you
are trying to do.
Maybe I'm making stuff overly complicated, but one way or the other a
lot of times I come up gui/layout/dom-updating things that has to be
dealt with in more than 1 place.