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 [EMAIL PROTECTED] -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: action and form contract
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] 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
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 [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: action and form contract
I've often wondered what other people do for this sort of thing.
Here's my style for constructive comment. (no insults please!).
I'm trying to write code that can run for 10 years be easy to maintain.
==
1 - Handling form pointer null -
My preferred style in perform method is below.
The comment is in the 'reference' code - ie. the best example
to be used as a model for other code. Not that I totally
stick to it - but wish I did!
Maybe overkill but I try to code for
1 - Robustness/Defensiveness. Help people when they misuse your program.
2 - An error has 1 cause that cause is obvious.
3 - De-skill troubleshooting/problem fixing.
/*
* ClassCastException or NullPointerException is caused by
* a struts-config.xml set-up error or a bug.
* (This comment for reference code only - remove in copied code)
*/
LinkListForm thisForm = (LinkListForm) form;
===
2 - Exception handling.
Often it's not enough to let a NullpointerException do the talking
as above but I validate input data that 'should' be right.
I have my own exception to indicate really obviously that it's raised by my
code not java or something else.
if (linkMaintLinkID == null) {
throw new BiffApplicationException(
bug in caller - linkMaintID null);
}
int selectedLinkID = 0;
try {
selectedLinkID = Integer.parseInt(linkMaintLinkID);
} catch (NumberFormatException nfe) {
throw new BiffApplicationException(
bug in caller - linkMaintID not integer: +
linkMaintID)
}
=
3 I use exceptions for technical problems - bugs or
incorrect deployment. But not for user validation errors.
4 - Never hide diagnostic information. (I get excitable about this!).
This code is from ActionServlet.
String value = getServletConfig().getInitParameter(debug);
try {
debug = Integer.parseInt(value);
} catch (Throwable t) {
debug = 0; // ---
}
I would code this to either throw exceptions or log warnings:-
- ActionServlet: Warning- servlet Init parm: debug not found defaulting to 0
- ActionServlet: Warning- servlet Init parm: debug=. Not integer. using 0
==
--- Carter, Steve [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
=
~~
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!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: action and form contract
Hi I have been reading all the emails from this mailing list, and found it quite time consuming opening one, read, closing one then opening another... I wonder if I can view these messages through a web? like something for JavaRanch and any other web sites where posting/answering questions are all through the web. If so, what is the site address? Thanks very much for an answer. Yanhui Yu === Pioneer HiBred International, Inc. 515-253-2122 -Original Message- From: Carter, Steve [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 11:09 AM To: Struts-User (E-mail) Subject: action and form contract 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 [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
