You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by jt...@honda.co.nz on 2004/10/04 00:51:20 UTC

Java edit method - design pattern? (O/T)





I'm working on an application API to be deployed with struts, and am
interested in how other developers are dealing with 'editing' methods, ie
methods that answer a question with a true/false value, but if false is
returned, you also want to know why.

for example, a credit card application may have a method 'boolean
allowCreditFor(int cashAmount)' which returns true if the amount requested
is ok, but false if not.
But what if you want to know why false is returned?

Using an Exception seems to be a pretty good fit, but doesn't seem to me to
be in keeping with its purpose (ie that an Exception should signal an
abnormal outcome that couldn't be handled locally).

Thanks for your thoughts,

John Thompson


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


RE: Java edit method - design pattern? (O/T)

Posted by "David G. Friedman" <hu...@ix.netcom.com>.
John,

Could you pass an ActionMessages object as the second parameter to your
method?  That way, you still return your boolean but you could 'push' an
ActioMessage on the ActionMessages 'stack' for display in an error JSP.  If
you are worried about keeping your business methods separate from Struts,
you could pass an empty (but instantiated) (Jakarta commons?) collection
type.  Back in the invoking method, if the boolean is false, you could
iterate through the collection and add those String messages (or whatever
they were that you put into the collection) into ActionMessages for display
in your JSP.

I'm eager to see what other solutions are suggested by Struts users.   I'm
sure we'll see many different opinions, all quite effective. :)

Regards,
David

-----Original Message-----
From: jthompson@honda.co.nz [mailto:jthompson@honda.co.nz]
Sent: Sunday, October 03, 2004 6:51 PM
To: Struts Users Mailing List
Subject: Java edit method - design pattern? (O/T)

I'm working on an application API to be deployed with struts, and am
interested in how other developers are dealing with 'editing' methods, ie
methods that answer a question with a true/false value, but if false is
returned, you also want to know why.

for example, a credit card application may have a method 'boolean
allowCreditFor(int cashAmount)' which returns true if the amount requested
is ok, but false if not.
But what if you want to know why false is returned?

Using an Exception seems to be a pretty good fit, but doesn't seem to me to
be in keeping with its purpose (ie that an Exception should signal an
abnormal outcome that couldn't be handled locally).

Thanks for your thoughts,

John Thompson


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org