Weights for Drupal.behaviors

@Damien,
I was going to add that comment myself, bug my Karma on drupal.stackexchange does not allow it yet..
http://stackoverflow.com/questions/648139/is-the-order-of-fields-in-a-ja...
http://stackoverflow.com/questions/280713/elements-order-for-in-loop-in-...

We can read that most (all relevant?) browsers behave "as we would expect".
This being said, this is even one more argument that behavior order should be controllable with a weight setting.

The attachBehaviors should look at the Drupal.behaviors object and any weight information it can find, then transform the thing into an array (or an array of objects, so the real behaviors are found one level further down the hierarchy).
Then we need some mechanics that allow other modules to manipulate the behaviors, after they have been "transformed" (so we don't have to run this every time that attachBehaviors() is called).

Could you explain how AMD changes the order of behaviors?
The issue you linked does not seem to have a sufficient explanation (or it is hidden somewhere).

----------

"Dependencies", the way I understand it, means that one component that knows two behaviors, can tell us which of those should be executed before the other. Those components would have to take care to not declare any cyclic dependencies etc.

"Weights", on the other hand, can control the order of behaviors that are unknown to each other. That means, a component does not need to know both behaviors, to give one of them a weight of -1.

Both of these concepts have their legitimate use cases, although in practice it is often sufficient to work with weights only.
Using a combination of them could result in priority conflicts, but this is not any worse than the cyclic dependencies issue mentioned above.

----

ALso, as Damien Tournoud points out in #5, this is about order of behaviors, not the order of script files.

One script file A can register any number of behaviors, with different weights. With behavior_weights module, there could even be another script file B that would change the order (weight) of behaviors registered in script A. The load / execution order of A and B would be completely irrelevant.

Use cases can be so distracting.
(I had one, but I don't remember it atm.)

Ok, I grepped my codebase and found two use cases.

In general, the idea is that I want to do some client-side manipulations on the html, before a mechanic (slider etc) kicks in.
E.g., set an explicit width on an element based on a dynamic calculation, before jquery.cycle does it (with the wrong values).
This was one case.

In the other case I found, on hindsight, the weight was not necessary at all :) No matter which weight I put there, the click-popup-fade mechanic did still work. Probably I just put it there during a troubleshooting, and forgot to remove.

And then there is this drupal.stackexchange discussion,
http://drupal.stackexchange.com/questions/1673/how-can-i-control-the-ord...
Unfortunately, the guy does not tell us about the use case (and I have insufficient karma to comment :) )

In this jQuery cycle issue, can you tell me how changing the #weight attribute in the drupal_add_js wouldn't work?

The #weight controls the order of javascript files, and thus, in which order the behaviors are added into the array.

However, As explained in the stackexchange discussion and supported by referenced articles, the order in which properties are added to an object in javascript does not guarantee the order in which they are looped through.

See
Is the order of fields in a javascript object predicatble when looping through them? and
Elements order - for (… in …) loop in javascript.
and also Damien's comment in #1.
I thought we are past this point :)

Besides, having the behavior weight as a separate mechanic, does allow us to add different behaviors with different weights, all from the same js file.

Btw, about use cases: I had a comment in the queue of behavior_weights:
#1700360: proper implementation

Ok, so in this case it would better be solved with dependencies, aka "run A before B".

Following #1446166-22: Use JS events instead of Drupal.behaviors and #1446166-27: Use JS events instead of Drupal.behaviors:
We move to events for the internal implementation, and this will change the signature of attach() methods to expect an event argument.
However, the registration of behaviors would still be quite similar: You create an object Drupal.behaviors.my_behavior with an attach() method, and drupal.js will register it automatically. (If I understand correctly).

Instead of the module js explicitly saying ".bindBefore()", I think it would be preferable if you can simply give the behavior object a dependencies attribute.

E.g.
Drupal.behaviors.my_behavior.run_before.another_behavior = true;

As mentioned in #7, we can have both, or only one of: behavior.weight, and behavior.run_before / .run_after.
This said: I wonder how event handler dependencies can be dealt with outside Drupal behaviors attach() stuff. How does it work with jQuery events, for instance?

And how can .bindBefore() recognize string keys, if events are registered with numeric keys? (remember, string key attributes have undefined order)

The use case is having a way to run behaviors after/before another one. Weights are a poor way of solving this problem.

There are actually two use cases, as explained in #7. One is best solved with weights, the other is best solved by saying "A must run before B".

In which cases would you want to order behaviors that are unknown to each other? It seems to me that if they don't know about each other, they have no business trying to execute before or after another.

It is more like "I want to run later than most of the other behaviors" or "I want to run before most of the other behaviors". If you are very sure about this, you choose weight = 999 or -999. If you want to give other behaviors a chance, you choose 10 or -10 instead.

This is the same with modules and hooks.

Finding a specific use case is difficult because most of the time I spend on PHP, not on javascript. Or if I develop some javascript, I rarely get in touch with behaviors.

Let's say we have an ordered list of behaviors. If we run them in order there is no guarantee the previous behavior will be completely finished before launching the next one (there are behaviors with ajax calls in them, see edit module)

This would be the same with other ways of prioritization ("A after B" style). The synchronous part is ordered, the asynchronous part is not.

To clarify: I do not have a strong use case atm. The one mentioned by cweagans seems to be more of the "A after B" style, where both A and B are known. I am defending my argument, but do not necessarily insist on a specific outcome.

pointing to comment #1, which points out that drupal_add_js() weight or module weight is not a reliable solution.

Just for the record:
https://www.drupal.org/project/behavior_weights now reports 890 installs.

And I just ran into a use case myself, where I want to run a custom behavior after a contrib behavior (atom_reference.js, in scald project), to alter the html generated there (for the <div class="atom_reference_operations">).
This would actually be better (or semantically cleaner) solved by the dependency model as suggested by nod_, instead of numeric weights. But the numeric weights will do the trick.
(We can discuss whether atom_reference.js does a good thing here, but let's just assume it is unchangeable.)