You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Carter, Steve" <SC...@swiftrivers.com> on 2002/03/05 14:48:55 UTC
RE: action and form contract
Thanks. That's clear. However -- not to nit-pick, but -- in the first paragraph you have "contact" and it appears you mean "contract".
Steve
Steve Carter
Sr. Software Engineer
Swift Rivers
scarter@swiftrivers.com
-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Friday, February 22, 2002 5:10 AM
To: Struts Users Mailing List
Subject: Re: action and form contract
How about this:
Do not blindly check for null ActionForm beans in all your Actions
If an Action expects an ActionForm bean, then its API contact with the
ActionMappings should require that a particular ActionForm bean, or
subclass thereof, be named in the ActionMapping. The Action's contract
with the controller is that it will always instantiate the bean before
the Action is called. If either contract is broken, the application
should expose a null pointer exception so that the programming error is
fixed and the misunderstanding resolved. Whether an Action expects an
ActionForm bean should be specified in its Javadoc.
Alternatively, the perform method should provide a general check of all
its preconditions, including, but not limited to, the existance of an
ActionForm bean.
Do check for essential preconditions in your Actions
The perform method in the Action is a key hotspot in the framework, and
may be realizing several different API contracts. To be sure all the
contracts are being met, provide a general error catching routine for
your Actions. This can look for any number of preconditions including
whether there is a form bean when one is expected, and whether it is of
the requesite class, and provide the appropriate error messages.
See the SuperAction class in the Scaffolding package for a working
example. Scaffolding can be found in the Contrib folder of the nightly
build.
-- Ted Husted, Husted dot Com, Fairport NY US
-- Developing Java Web Applications with Struts
-- Tel: +1 585 737-3463
-- Web: http://husted.com/about/services
"Carter, Steve" wrote:
>
> On husted.com, Ted Husted wrote:
> Do not check for null ActionForm beans in your Actions
> If an Action expects an ActionForm bean, then its API contact with the ActionMappings should require that this bean, or a subclass, be named in the ActionMapping. The Actions contact wit the controller is that it will always instantiate the bean before the Action is called. If either contact is broken, the application should expose a null pointer exception so that the problem is fixed and the misunderstanding resolved. Whether an Action expects an ActionForm bean should be specified in its Javadoc.
>
> Now I'm wondering if 'contact' was a type and what he meant was 'contract', that is, in the sense of an API contract or implied constrain, pre-condition.
>
> (You out there Ted?)
>
> Anyway, this seems like a good idea. I'm always complaining that exceptions are often overused or misused in Java, and this seems like a good use: let the exception raise havoc, in order to inform you of a really exceptional condition, and one that should be exposed if it exists.
>
> Steve Carter
> Sr. Software Engineer
> Swift Rivers
> scarter@swiftrivers.com
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: action and form contract
Posted by keithBacon <ke...@yahoo.com>.
>>Do check for essential preconditions in your Actions
I agree with that! Defensive / Controlled State programmimg makes debugging
much simpler. makes code easier to read too.
>> The perform method in the Action is a key hotspot in the framework, and
>>may be realizing several different API contracts.
I struggle a bit with handling multiple pre-conditions, the code gets messy
quite quickly & my system isn't even very sophisticated. Also I hate passing
parameters in maps (ie. as name/value pairs).
I'm extending the discussion from form/action contract to the 'contract'
beteween actions.
For a create/update action class that is forwarded to from a data list action
class, I set up a data only object that represents
1 - the input parms
2 - the data that is to be returned to the thing that called it.
3 - the action name of the action to return to after the update.
When the user clicks a link in the list - The list action starts up , puts the
parm object in the session & forwards to the maint action.
This handles the rudimentary workflow case of the maint action returning to the
list that forwarded to it. The list has access to the key of the thing just
updated in case it wants to display it.
==========
class reviewMaintParmsDO
// struts action to be forwarded to on completion - normally used
// to allow return to the list page that invoked the main function.
// Value must be defined as a <forward name in the maint <action.
String inChainToAction
// passed in or out - message to display on next page.
String inoutNextPageMessage
// set these to invoke maintenance function.
int inReviewMaintLinkId
int inReviewMaintReviewId
// Set this to invoke create function.
int inReviewCreate LinkId
// Set by create function - Id of review created.
int outReviewCreateReviewId
Does this look any good?
Does any-one else do similar?
It made the start-up code for the maint action class much simpler & made the
'contract' beween the list & maint actions explicit.
Keith.
--- "Carter, Steve" <SC...@swiftrivers.com> wrote:
> Thanks. That's clear. However -- not to nit-pick, but -- in the first
> paragraph you have "contact" and it appears you mean "contract".
>
> Steve
>
> Steve Carter
> Sr. Software Engineer
> Swift Rivers
> scarter@swiftrivers.com
>
>
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Friday, February 22, 2002 5:10 AM
> To: Struts Users Mailing List
> Subject: Re: action and form contract
>
>
> How about this:
>
> Do not blindly check for null ActionForm beans in all your Actions
>
> If an Action expects an ActionForm bean, then its API contact with the
> ActionMappings should require that a particular ActionForm bean, or
> subclass thereof, be named in the ActionMapping. The Action's contract
> with the controller is that it will always instantiate the bean before
> the Action is called. If either contract is broken, the application
> should expose a null pointer exception so that the programming error is
> fixed and the misunderstanding resolved. Whether an Action expects an
> ActionForm bean should be specified in its Javadoc.
>
> Alternatively, the perform method should provide a general check of all
> its preconditions, including, but not limited to, the existance of an
> ActionForm bean.
>
> Do check for essential preconditions in your Actions
>
> The perform method in the Action is a key hotspot in the framework, and
> may be realizing several different API contracts. To be sure all the
> contracts are being met, provide a general error catching routine for
> your Actions. This can look for any number of preconditions including
> whether there is a form bean when one is expected, and whether it is of
> the requesite class, and provide the appropriate error messages.
>
> See the SuperAction class in the Scaffolding package for a working
> example. Scaffolding can be found in the Contrib folder of the nightly
> build.
>
> -- Ted Husted, Husted dot Com, Fairport NY US
> -- Developing Java Web Applications with Struts
> -- Tel: +1 585 737-3463
> -- Web: http://husted.com/about/services
>
>
> "Carter, Steve" wrote:
> >
> > On husted.com, Ted Husted wrote:
> > Do not check for null ActionForm beans in your Actions
> > If an Action expects an ActionForm bean, then its API contact with the
> ActionMappings should require that this bean, or a subclass, be named in the
> ActionMapping. The Actions contact wit the controller is that it will always
> instantiate the bean before the Action is called. If either contact is
> broken, the application should expose a null pointer exception so that the
> problem is fixed and the misunderstanding resolved. Whether an Action expects
> an ActionForm bean should be specified in its Javadoc.
> >
> > Now I'm wondering if 'contact' was a type and what he meant was 'contract',
> that is, in the sense of an API contract or implied constrain, pre-condition.
> >
> > (You out there Ted?)
> >
> > Anyway, this seems like a good idea. I'm always complaining that exceptions
> are often overused or misused in Java, and this seems like a good use: let
> the exception raise havoc, in order to inform you of a really exceptional
> condition, and one that should be exposed if it exists.
> >
> > Steve Carter
> > Sr. Software Engineer
> > Swift Rivers
> > scarter@swiftrivers.com
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
=====
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Search the archive:-
http://www.mail-archive.com/struts-user%40jakarta.apache.org/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Keith Bacon - Looking for struts work - South-East UK.
phone UK 07960 011275
__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>