[
https://issues.apache.org/jira/browse/TAP5-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Zeigler updated TAP5-777:
--------------------------------
Fix Version/s: (was: 5.2)
5.2.0.0
> 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
> Assignee: Robert Zeigler
> Fix For: 5.2.0.0
>
>
> 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.
