Just to answer my own question: dug around a bit, and no, it doesn't look like that would be easily achievable. However, (the unordered) Configuration is internally implemented as a list, so surprisingly that's a better match for my use case (as long as the implementation doesn't suddenly change). Still, it'd be simple to offer some lightweight interface for wrapping up both the key and the value (even for auto-generating the key) in case the user has a use for keys later in the service.
Kalle On Thu, May 26, 2011 at 11:47 AM, Kalle Korhonen <kalle.o.korho...@gmail.com> wrote: > Let me ask again in more simple terms - is it currently possible to > access the contribution element ids of an OrderedConfiguration in a > service? Looking through the code but you probably know the answer > right off the bat. > > Kalle > > > On Thu, May 26, 2011 at 12:08 AM, Kalle Korhonen > <kalle.o.korho...@gmail.com> wrote: >> 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
