You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org> on 2006/07/27 17:12:14 UTC
[jira] Commented: (TAPESTRY-1022) Ordering with pre/post requisites
could be simplified, improved
[ http://issues.apache.org/jira/browse/TAPESTRY-1022?page=comments#action_12423856 ]
Howard M. Lewis Ship commented on TAPESTRY-1022:
------------------------------------------------
This ordering logic is used in two places: ordering of decorators for a service, and ordering of contributions to an OrderedConfiguration.
> Ordering with pre/post requisites could be simplified, improved
> ---------------------------------------------------------------
>
> Key: TAPESTRY-1022
> URL: http://issues.apache.org/jira/browse/TAPESTRY-1022
> Project: Tapestry
> Issue Type: Improvement
> Components: IoC Container
> Affects Versions: 5.0
> Environment: Tapestry 5 alpha code
> Reporter: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.0
>
>
> The Ordering logic is based on pre and post requisites, showing up as @After and @Before annotations, and corresponding method parameters.
> I think this is limiting.
> I would like to coalesce @After and @Before into just @Order. The value for @Order is a list of constraint strings.
> A constraint string is a type, a colon, and a list of service ids. The type can be "before", "after" or "within".
> Example: before:Security,Transaction
> Within will allow orderings to be broken up easily into phases. Once a "phase" is defined with before and after constrains, the "within:" constraint will order the element after the phase, but before the phase's post-requisites.
> Example:
> phase2 --> after:phase1, before:phase3
> object1 --> within:phase2
> object2 --> within:phase2 after:object1
> object1 ends up with the effective constraints after:phase1, before:phase3
> object2 ends up with the effective constraints: after:phase1, object1 before:phase3
> This works well with the fact that null objects may be contributed into an ordering as placeholders (but are editted out of the final list).
> From experience, this is very necessary. The Tapestry 4 enhancement process would certainly have benefited from this.
> Finally, Tapestry 5 has reasonable "glob" matching of service ids and the list of constraints should work from that. Currently, the code (imported from HiveMind) only recognizes a single glob, "*".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org