You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Hubert Rabago <hr...@gmail.com> on 2005/09/09 22:33:04 UTC
On DynaForms (was: Re: DO NOT REPLY [Bug 33066] - Lazy Validator Action Form)
> ------- Additional Comments From mrdon@twdata.org 2005-09-09 22:18 -------
> I'm personally -0 against adding this patch, mainly because I think we should
> get rid of those confusing sister classes altogether.
I wanted to get some opinion on a related issue. Someone posted a
ResettableDynaForm patch for FormDef
(https://formdef.dev.java.net/issues/show_bug.cgi?id=2) and while I
agree that this is something that the framework should handle (unsure
which framework should handle it, though), I'm uncomfortable with the
idea of a ResettableDynaForm because then I'd have to worry about all
the other sister classes. (This one just extends DynaActionForm.)
I'm surprised I haven't encountered this problem before. Is there a
common solution I'm not aware of? If there aren't any, is there
something we can do to fix it?
> They should be moved to
> some sort of "extras" subproject or something far away from the main framework.
Either move them or consolidate them somehow.
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: On DynaForms
Posted by Don Brown <mr...@twdata.org>.
Of course, if you are going to do that, why not just let them specify
the validation key right there? What about both? At the form bean level:
<form-bean ...>
<set-property key="useForValidationKey" value="path|name" />
</form-bean>
Alternatively at the action mapping level:
<action ...>
<set-property key="validationKey" value="fooForm" />
</action>
Don
Niall Pemberton wrote:
>+1 - but maybe it should be the <set-property> element for action mappings -
>thats whats passed to the validate() and getValidationKey() methods.
>
>Niall
>
>----- Original Message -----
>From: "Don Brown" <mr...@twdata.org>
>Sent: Friday, September 09, 2005 9:46 PM
>
>
>
>
>>What if we consolidated them by using the <set-property> element for
>>form beans to configure whether the path or name should be used? Of
>>course we'd have to deprecate the existing classes, but at least we
>>could move them for 1.4.
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: On DynaForms
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
+1 - but maybe it should be the <set-property> element for action mappings -
thats whats passed to the validate() and getValidationKey() methods.
Niall
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
Sent: Friday, September 09, 2005 9:46 PM
> What if we consolidated them by using the <set-property> element for
> form beans to configure whether the path or name should be used? Of
> course we'd have to deprecate the existing classes, but at least we
> could move them for 1.4.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: On DynaForms
Posted by Don Brown <mr...@twdata.org>.
Hubert Rabago wrote:
>>------- Additional Comments From mrdon@twdata.org 2005-09-09 22:18 -------
>>I'm personally -0 against adding this patch, mainly because I think we should
>>get rid of those confusing sister classes altogether.
>>
>>
>
>I wanted to get some opinion on a related issue. Someone posted a
>ResettableDynaForm patch for FormDef
>(https://formdef.dev.java.net/issues/show_bug.cgi?id=2) and while I
>agree that this is something that the framework should handle (unsure
>which framework should handle it, though), I'm uncomfortable with the
>idea of a ResettableDynaForm because then I'd have to worry about all
>the other sister classes. (This one just extends DynaActionForm.)
>
>I'm surprised I haven't encountered this problem before. Is there a
>common solution I'm not aware of? If there aren't any, is there
>something we can do to fix it?
>
>
>
>>They should be moved to
>>some sort of "extras" subproject or something far away from the main framework.
>>
>>
>
>Either move them or consolidate them somehow.
>
>
What if we consolidated them by using the <set-property> element for
form beans to configure whether the path or name should be used? Of
course we'd have to deprecate the existing classes, but at least we
could move them for 1.4.
Don
>Hubert
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org