You should "VERY RARELY" ever need to call an action from an another
action and never in the case of business logic. If you have stuff you
need to do from more than one action then you should move it out into
some helper class. I often have a UIhelper class that handles dealing
with certain com
While I 100% agree with the theory and separate the layers as much as
possible in my own code, I can't say I've never broken the rules (and I
doubt any of you can frankly). I also know that in development,
especially in a corporate environment where the emphasis many times is
on just getting t
It may not have been the answer the original poster was looking for, but
it is the correct way to solve this problem. Action methods should only
be used as direct responses to a single user action. Business delegate
behaviors should be aggregated and reused by different actions.
> -Original
The trick is to make your action classes very "thin" i.e. implement as much
logic as you possible can in your delegate without violating separation of
concerns. This way it becomes less of a problem making your actions fine
grained and have a number of actions reusing logic in your delegate lay
Hello,
Shame on me :-(
It was enough to extend XAction to get the method that gets the data
And put it into the session..
Sorry all
Regards
marco
-Original Message-
From: Marco Mistroni [mailto:[EMAIL PROTECTED]
Sent: 08 October 2004 12:33
To: 'Struts Users Mailing List'
5 matches
Mail list logo
