All that Preparable does is tells the PreparableInterceptor to call your prepare() method. It doesn't require any other methods, so I'm not sure why that would cause empty actions...
On the other hand, if you have clusters of code that require common support objects, the Interceptor can be your friend. Create a PersonAware interface with a setPerson() method. Then create a PersonInterceptor and add it to your stack. Whenever the PersonInterceptor intercepts a request for an action that implements PersonAware, look up the Person in the Session, Retrieve it from the DB, or Create an Empty one (whatever is appropriate for your circumstances) and pass it in the setPerson() method for the action to use. (*Chris*) On Wed, Apr 27, 2011 at 6:29 AM, Miguel <mig...@almeida.at> wrote: > Thanks for the prompt reply Dave. I have a couple of follow-up questions > regarding this. > > On Wed, 2011-04-27 at 08:59 -0400, Dave Newton wrote: > > > It's not making a separate *browser* request, it's all internal to S2. > > > > Does this mean that struts' FAQ in > > https://cwiki.apache.org/WW/how-do-we-repopulate-controls-when-validation-fails.htmlis > incorrect in suggesting s:action for this? > > > > Personally, I think things like this are better handled through > > Preparable or similar mechanism. > > > > I haven't used the Preparable approach much, mainly because my actions > are usually grouped by domain objects. Eg: I'll have a PersonAction > where I'll put a add, list, remove methods which I'll map actions to. > This saves a bit of configuration in things like adding the > corresponding service (personService) and setter. With a preparable I'll > have: > > 1) unused logic (say, if I have a findPerson() method/action, it won't > probably need a list = personService.getAll() that I'll put in my > preparable method. So an extra db call > > 2) funny looking empty actions (eg: the list() method/action will now be > an empty return "something", because the logic is in the preparable. > Isn't this odd-looking? > > > That said, I don't use validation very often. It appears to over > complicate things a bit (a bit egg vs chicken theory, perhaps that's why > I don't use it very often). > > Regards, > > Miguel >
