Hi,

On Thu, Dec 11, 2008 at 11:40 PM, Andreas Joseph Krogh
<andr...@officenet.no> wrote:
> On Thursday 11 December 2008 23:31:46 Ronny Løvtangen wrote:
>> On Dec 11, 2008, at 11:26 PM, Musachy Barroso wrote:
>>
>> > The problem with your suggestion is that it works for simple, and
>> > specific cases, but given OGNL "power", there is a large way of cases
>> > when it would break. Like
>> >
>> > <s:push value="foo">
>> >       <s:iterator value="bars[#action.index - 1 * Math.PI]">
>> >               <s:textfield name="baz"  />
>> >       </s:iterator>
>> > </s:push>
>> >
>> > what would the name be in that case?
>>
>> How would you handle the request parameters from this form?
>> Most of the time you don't do such power OGNL expressions in a form,
>> you're just interested in updating some objects in a collection.
>
> I think the use-case for such power-OGNL expressions in a form is less than 
> 1%. I must say I've created quite a lot of web-apps and forms over the years 
> and *never* had any requirement where the above would be a relevant solution 
> to anything. Documenting this limitations whold be OK I think.


In general I think your idea is quite a good one, but saving code or
expressions is always good to simplify things, even if the code is a
little harder to comprehend.

On the other hand, this will simplify things only on a certain set of
problems, when the form which was generated in the first request posts
to an action with exactly the same setup for the ParametersInterceptor
to inject (read "will mostly help with CRUD actions"). In addition the
developer has to know that the tags your are patching up might work in
the "fully qualified mode" or in the "nested mode", which will add
additional confusion for the vanilla developer out there. It has to be
clear in which circumstances the tags in questions work either way.

I suggest to leave the default behaviour as-is for now, but give the
guys who want it a switch somewhere.

Cheers,
-Ralf

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Reply via email to