Thread: Re: [Webwork-devel] Validation on commands?
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel
|
From: <Jim...@do...> - 2002-03-11 13:30:49
|
-1
I'm against hardcoding validation on every command action=20
indescriminately. But then again, I'm against hardcoding validation check=20
in doExecute. From a practical standpoint, many of us who use the=20
CommandDriven design, do so in order to "setup" a page. This is a very=20
common step with no need for validation. Putting an extraneous check in=20
these cases does not feel like good design.
I think the action designer can choose to call doValidation (or validate)=20
when they feel it is appropriate. If they want the blanket validation, it=20
is trivial to add to an ActionSupport subclass, however if it is embedded=20
as the default behavior, then the options narrow.=20
jim
Rickard <ri...@mi...>
Sent by: web...@li...
03/11/2002 04:24 AM
=20
To: WebWork Development <web...@li...>
cc:=20
Subject: [Webwork-devel] Validation on commands?
Hey
What was the result of our discussions re: validating data on commands=20
as well? I recall that we said that it would be a good idea to call=20
validation() regardless of whether doExecute() or a command was to be=20
invoked.
That's ok, but then all examples break since validation is called before=20
doDefault() is invoked. So, either the examples has to be updated so=20
that the validation rules are surrounded with
if (!isCommand("default"))
{
..
}
or, we could special-case the validation so that it's not done before=20
executing "default" but it's done on all other commands.
What say ye?
/Rickard
--=20
Rickard =D6berg
Author of "Mastering RMI"
Chief Architect, TheServerSide.com
The Middleware Company - We Build Experts!
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Webwork-devel mailing list
Web...@li...
https://lists.sourceforge.net/lists/listinfo/webwork-devel
|
|
From: <ma...@sm...> - 2002-03-11 14:01:07
|
Why can't we add a boolean flag, useExplicitValidation(), or something to turn it on or off? On Mon, 11 March 2002, Rickard wrote >=20 > Jim...@do... wrote: >=20 > > -1 > > I'm against hardcoding validation on every command action=20 > > indescriminately. But then again, I'm against hardcoding validation check=20 > > in doExecute. From a practical standpoint, many of us who use the=20 > > CommandDriven design, do so in order to "setup" a page. This is a very=20 > > common step with no need for validation. Putting an extraneous check in=20 > > these cases does not feel like good design. >=20 >=20 > I personally use commands for CRUD operations (i.e. one action with=20 > modifying 3 commands plus execute() for Read). In my case validation is=20 > hence used for the commands but not necessarily for execute(). >=20 > How are others using commands? >=20 >=20 > > I think the action designer can choose to call doValidation (or validate)=20 > > when they feel it is appropriate. If they want the blanket validation, it=20 > > is trivial to add to an ActionSupport subclass, however if it is embedded=20 > > as the default behavior, then the options narrow.=20 >=20 >=20 > Ok, so in your view we should remove the call to validate() entirely=20 > from execute()? I.e. it should always be explicit whether validation is=20 > used or not? I can see your point.. it would make things much more explicit. >=20 > This is a big decision... what are other's opinion on this? >=20 > /Rickard >=20 >=20 > --=20 > Rickard =D6berg > Author of "Mastering RMI" > Chief Architect, TheServerSide.com > The Middleware Company - We Build Experts! >=20 >=20 > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel =0D |
|
From: Rickard <ri...@mi...> - 2002-03-11 14:04:54
|
ma...@sm... wrote: > Why can't we add a boolean flag, > useExplicitValidation(), or something to turn it on or > off? Hm.. that would be way too confusing I think. It would allow differences=20 between different developers working on the same project that would=20 confuse the code too much. No, either always or never. Implicit or explicit. /Rickard --=20 Rickard =D6berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! |
|
From: <ma...@sm...> - 2002-03-11 14:20:13
|
Then I vote explicit. On Mon, 11 March 2002, Rickard wrote >=20 > ma...@sm... wrote: >=20 > > Why can't we add a boolean flag, > > useExplicitValidation(), or something to turn it on or > > off? >=20 >=20 > Hm.. that would be way too confusing I think. It would allow differences=20 > between different developers working on the same project that would=20 > confuse the code too much. >=20 > No, either always or never. Implicit or explicit. >=20 > /Rickard >=20 > --=20 > Rickard =D6berg > Author of "Mastering RMI" > Chief Architect, TheServerSide.com > The Middleware Company - We Build Experts! =0D |
|
From: Dan B. <ch...@ch...> - 2002-03-11 15:20:18
|
how about marker interfaces? implements Validatable implements CommandValidatable or something... On Mon, 11 March 2002, ma...@sm... wrote: > > Then I vote explicit. > > On Mon, 11 March 2002, Rickard wrote > > > > > ma...@sm... wrote: > > > > > Why can't we add a boolean flag, > > > useExplicitValidation(), or something to turn it on > or > > > off? > > > > > > Hm.. that would be way too confusing I think. It > would allow differences > > between different developers working on the same > project that would > > confuse the code too much. > > > > No, either always or never. Implicit or explicit. > > > > /Rickard > > > > -- > > Rickard Öberg > > Author of "Mastering RMI" > > Chief Architect, TheServerSide.com > > The Middleware Company - We Build Experts! > > > > _______________________________________________ > Webwork-devel mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Rickard <ri...@mi...> - 2002-03-11 15:43:58
|
Dan Bachelder wrote: > how about marker interfaces? >=20 > implements Validatable=20 > implements CommandValidatable That is semantically almost equivalent to the suggestion that Matt had.=20 With the same drawbacks. /Rickard --=20 Rickard =D6berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! |
|
From: Rickard <ri...@mi...> - 2002-03-12 09:17:44
|
Low Heng Sin wrote: > non-cmd action - validate() -> doValidate() > cmd-action - doDefault() -> doDefaultValidate() > doEdit() -> doEditValidate() > doCreate() -> doCreateValidate() >=20 > The validate for cmd-action should be optional and implemented using > reflection ( just like how cmd work ). Preferably not. It is quite common (at least for me) that validation=20 rules needs to be shared between two or more commands, so splitting them=20 up is not a good idea. /Rickard --=20 Rickard =D6berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! |
|
From: Matt B. <ma...@sm...> - 2002-03-12 12:47:07
|
IMHO, I believe this is why it should be explicit. You have cases where it should be shared, not used, and separate. ----- Original Message ----- From: "Rickard" <ri...@mi...> To: "Low Heng Sin" <lo...@co...> Cc: <web...@li...> Sent: Tuesday, March 12, 2002 3:16 AM Subject: Re: [Webwork-devel] Validation on commands? Low Heng Sin wrote: > non-cmd action - validate() -> doValidate() > cmd-action - doDefault() -> doDefaultValidate() > doEdit() -> doEditValidate() > doCreate() -> doCreateValidate() > > The validate for cmd-action should be optional and implemented using > reflection ( just like how cmd work ). Preferably not. It is quite common (at least for me) that validation rules needs to be shared between two or more commands, so splitting them up is not a good idea. /Rickard -- Rickard Öberg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! _______________________________________________ Webwork-devel mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webwork-devel |
|
From: Rickard <ri...@mi...> - 2002-03-12 12:51:28
|
Matt Baldree wrote: > IMHO, I believe this is why it should be explicit. You have cases where= it > should be shared, not used, and separate. Ok, I will then leave it as-is: validation will always be done for=20 doExecute() (i.e. implicitly), and needs to be called explicitly for=20 commands. /Rickard --=20 Rickard =D6berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! |
|
From: Rickard <ri...@mi...> - 2002-03-11 13:38:11
|
Jim...@do... wrote: > -1 > I'm against hardcoding validation on every command action=20 > indescriminately. But then again, I'm against hardcoding validation che= ck=20 > in doExecute. From a practical standpoint, many of us who use the=20 > CommandDriven design, do so in order to "setup" a page. This is a very=20 > common step with no need for validation. Putting an extraneous check in= =20 > these cases does not feel like good design. I personally use commands for CRUD operations (i.e. one action with=20 modifying 3 commands plus execute() for Read). In my case validation is=20 hence used for the commands but not necessarily for execute(). How are others using commands? > I think the action designer can choose to call doValidation (or validat= e)=20 > when they feel it is appropriate. If they want the blanket validation, = it=20 > is trivial to add to an ActionSupport subclass, however if it is embedd= ed=20 > as the default behavior, then the options narrow.=20 Ok, so in your view we should remove the call to validate() entirely=20 from execute()? I.e. it should always be explicit whether validation is=20 used or not? I can see your point.. it would make things much more explic= it. This is a big decision... what are other's opinion on this? /Rickard --=20 Rickard =D6berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! |
|
From: Maurice P. <Ma...@Vi...> - 2002-03-11 14:18:26
|
Hey, On Monday, March 11, 2002, at 07:37 AM, Rickard wrote: >> I think the action designer can choose to call doValidation (or validate) >> when they feel it is appropriate. If they want the blanket validation, >> it is trivial to add to an ActionSupport subclass, however if it is >> embedded as the default behavior, then the options narrow. > > > Ok, so in your view we should remove the call to validate() entirely from > execute()? I.e. it should always be explicit whether validation is used > or not? I can see your point.. it would make things much more explicit. > > This is a big decision... what are other's opinion on this? -1 This would break a lot of code that has relied on this behavior. I don't use Commands, so I don't have the same validation issues that you get with Commands. I simply don't implement doValidation() on Actions I don't want to validate. But if you remove validate() from execute() lots of my code has to be updated to go and explicitly call doValidate(). I'm sure there are others that will have the same problem. -Maurice |
|
From: Rickard <ri...@mi...> - 2002-03-12 09:01:18
|
Maurice Parker wrote: > This would break a lot of code that has relied on this behavior. I=20 > don't use Commands, so I don't have the same validation issues that you= =20 > get with Commands. I simply don't implement doValidation() on Actions I= =20 > don't want to validate. But if you remove validate() from execute()=20 > lots of my code has to be updated to go and explicitly call=20 > doValidate(). I'm sure there are others that will have the same proble= m. To me it sounds like most arguments thus far rely on "I need it to work=20 this way because otherwise my code breaks". Sure, I have code that would=20 need updating too (either way), but that's not really the concern right n= ow. If implicit -> need to add if's to validation code that switches on comma= nd. If explicit -> need to add validate()'s to execution/command code. Does anyone have an opinion that is based on the actual problem and not=20 their own situation? That would be more helpful. regards, Rickard --=20 Rickard =D6berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X