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).
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
wrote:
> On Wed, M
On Wed, May 25, 2011 at 10:30 PM, Howard Lewis Ship 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 i
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 som
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
wrote:
> I have a use case where I'd
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). Or
