I actually agree with Jack on this one. Ideally, you should architect your
application into layers:
+------------------+
| Application |
+------------------+
| Business Objects |
+------------------+
| DAO |
+------------------+
| Persistence |
+------------------+
The idea being that you can code the bottom three independent of the top
one - as well as unit and system test them independently. The
application-specific layer then does nothing but coordinate the conversation
between the application and your business rules. In a Struts application,
generally, the action classes are the place this coordination takes place.
Doing things this way buys you a lot that is hard for me to convey in words.
I'd strongly recommend using this approach though as it'll be far easier on
you down the road.
Regards,
Eddie Bush
----- Original Message -----
From: "Laurie Harper" <[EMAIL PROTECTED]>
To: <user@struts.apache.org>
Sent: Sunday, May 22, 2005 7:36 PM
Subject: Re: DynaActionForm and the 'pull' model
There's no code in the JSPs, though you could make the argument that
having the JSPs fetch the data they need, through whatever means, is
putting application logic in the JSPs. And yes, this is generally not
reommended. In this case it's minimal and the trade off is the flexibility
it provides anyone writing or modifying the JSPs. It's the best way to
provide an easily cusomizable solution without needing to provide Java
source code.
L.
Dakota Jack wrote:
You are just coding on the JSP page, which for reasons that have been
discussed to death is a bad idea. If you like it, have at it. But,
generally speaking this is a very bad idea.
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0521-4, 05/27/2005
Tested on: 5/28/2005 1:22:00 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
