[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
