On Wed, May 25, 2011 at 10:30 PM, Howard Lewis Ship <hls...@gmail.com> wrote: > Or, alternately, could you build your map from the ordered List? I > really think that having a single structure be ordered and keyed and > expecting IoC to make sense of that is going to open up a can of > ambiguities .... and that's in the substrate level of the IoC where > its hard to bring to bear some of the higher powered Tapestry features > to handle it. (*)
Yes, of course I *can*, but the problem is that it looks cumbersome to a casual user and it's not necessarily obvious to the user why it has to be done that way. This is for the purposes of tynamo-security, where users are essentially contributing new request filter pipelines (or, pipeline "sections"). For a proof-of-concept I'm doing exactly that, i.e. building a map from and ordered list. If interested, see http://svn.codehaus.org/tynamo/trunk/tapestry-security/src/test/java/org/tynamo/security/testapp/services/AppModule.java and http://svn.codehaus.org/tynamo/trunk/tapestry-security/src/main/java/org/tynamo/security/services/impl/SecurityConfiguration.java. Yes, I understand that this might be problematic for the IoC to handle. Of course, there are multiple ways to skin this particular cat, but I'm not quite sure what's the right way to go about it at the moment since every option I've considered so far comes with some trade-offs. What I really want, is a syntax something like this: newChain("/somepath/***").add(anon, "config").add(authc, "config") ... and make the order in which these filter chains (pipelines) are configured meaningful, at least within a particular contribution point. I suppose I could also scrap the whole plan of contributing elements, and contribute it all in one big object, but if there are multiple security configuration contribution points, that too becomes problematic. Well, back to the drawing board for now. Kalle > > (*) I.e., on the same footing as why its so hard to contribute new > coercers to TypeCoercer without triggering recursive service > construction errors. > > On Wed, May 25, 2011 at 10:27 PM, Howard Lewis Ship <hls...@gmail.com> wrote: >> Could the contributed objects know their names and have space for >> ordering values (the "before:" and "after:" strings)? In other words, >> could you simple order the map value() inside your service >> implementation? >> >> On Wed, May 25, 2011 at 9:42 AM, Kalle Korhonen >> <kalle.o.korho...@gmail.com> wrote: >>> I have a use case where I'd like to contribute key-value pairs but >>> preserve their ordering, i.e. I'd like to contribute elements to a >>> LinkedHashMap. Now, MappedConfiguration doesn't work since it doesn't >>> preserve the order (or in Tapestry terms, cannot be ordered after >>> elements are contributed). OrderedConfiguration would work (at least >>> for my use case) if I had an access to the ids of the contributed >>> elements. Would it be a complete heresy, if instead of a List, you >>> could optionally specify a LinkedHashMap (or a custom Tapestry type >>> for an immutable linked map)? Any better ideas for it? >>> >>> Kalle >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
