[
https://issues.apache.org/jira/browse/TAP5-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732417#action_12732417
]
Alfie Kirkpatrick commented on TAP5-777:
----------------------------------------
My main interest in this enhancement is to ensure that Javascript event
handlers are executed in a deterministic order, so would want to ensure that if
two mixins call renderSupport.addInit, we can control the order of init methods
which may then add onclick and other event listeners. Am assuming your approach
would achieve this.
> 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
>
> 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.
