You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2005/09/09 22:18:30 UTC
DO NOT REPLY [Bug 33066] -
Lazy Validator Action Form
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33066>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33066
------- 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. They should be moved to
some sort of "extras" subproject or something far away from the main framework.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
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
On DynaForms (was: Re: DO NOT REPLY [Bug 33066] - Lazy Validator Action Form)
Posted by Hubert Rabago <hr...@gmail.com>.
> ------- 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