Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
5.1.0.5
-
None
-
None
Description
Currently, the only ordering tapestry does on mixins is to ensure that render phase methods on @MixinAfter mixins are invoked after the corresponding component event handler.
Beyond that, ordering is stochastic. It would be nice if mixins were applied in a deterministic order. Consider the case where a mixin shortcuts some phase of rendering. Another mixin may need that phase to be executed to perform properly. With stochastic ordering, the resulting behavior is basically unknown and could vary from application executing to application execution. With deterministic ordering, the mixins could be defined in such a way that both mixins function properly.
As I see it, there are two ways this problem could be solved.
One is to have a simple, pre-defined ordering, something like: template mixins in the order they are defined, followed by mixins defined via the @Mixins annotation in the order listed, followed by the implementation mixins, in the order the field are defined in the class. This has the advantage of simplicity. However, I can imagine scenarios where one might want an instance mixin to execute before an implementation mixin. The ordering could be reverse, but then the opposite problem applies: what if you want something executed after?
A compromise would be something like: @Mixins mixins, @Mixin mixins, template-defined mixins. But this starts to get confusing.
An alternative approach would be to allow the ordering of mixins to be defined explicitly, similar to how ordered configurations are defined and processed. Something like:
<t:textfield t:mixins="mixina,mixinb;before:*,mixinc,mixind;after:mixina mixinb"/>
This would be backwards compatible in that:
<t:textfield t:mixins="mixina,mixinb,mixinc,mixind"/> would still function, and would function as before: stochastic ordering, whereas the first approach would slightly alter component/mixin behavior for previously defined component trees.