You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kalle Korhonen <ka...@gmail.com> on 2011/05/25 18:42:42 UTC
Ordered MappedConfiguration
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ordered MappedConfiguration
Posted by Kalle Korhonen <ka...@gmail.com>.
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
<ka...@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
> <ka...@gmail.com> wrote:
>> On Wed, May 25, 2011 at 10:30 PM, Howard Lewis Ship <hl...@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 <hl...@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
>>>> <ka...@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-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ordered MappedConfiguration
Posted by Kalle Korhonen <ka...@gmail.com>.
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
<ka...@gmail.com> wrote:
> On Wed, May 25, 2011 at 10:30 PM, Howard Lewis Ship <hl...@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 <hl...@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
>>> <ka...@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ordered MappedConfiguration
Posted by Kalle Korhonen <ka...@gmail.com>.
On Wed, May 25, 2011 at 10:30 PM, Howard Lewis Ship <hl...@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 <hl...@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
>> <ka...@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ordered MappedConfiguration
Posted by Howard Lewis Ship <hl...@gmail.com>.
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. (*)
(*) 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 <hl...@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
> <ka...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Ordered MappedConfiguration
Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ka...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org