[ https://issues.apache.org/jira/browse/TAP5-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731258#action_12731258 ]
Robert Zeigler commented on TAP5-777: ------------------------------------- After giving this some more thought, it seems like the "right" way to do this is option #2. 1) Allows the most flexibility 2) Preserves current behavior for existing component trees. > 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.