Tapestry should ensure that mixins are applied in a deterministic order.
------------------------------------------------------------------------
Key: TAP5-777
URL: https://issues.apache.org/jira/browse/TAP5-777
Project: Tapestry 5
Issue Type: Improvement
Affects Versions: 5.1.0.5
Reporter: Robert Zeigler
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
