Frank W. Zammetti wrote:
Since an ActionForm is no different from any other class as far as the
filter would be concerned, it can instantiate it and place it in the
appropriate scope, which would really only mean session, since I'm pretty
sure Struts would overwrite it if it was request-scoped... as long as you
name it the same way Struts would name it, it should work, Struts should
find it in session and everything would work as usual.
If you're going to put an ActionForm into session mightn't it make more
sense to put this in a request processor, as long as it's
Struts-dependent anyway? I dunno.
The benefit is that you can do all sorts of initialization on it in a
declarative fashion, including calling certain methods on it, or passing
it off to some other object to configure it for you. It's what I call a
"hybrid IoC" implementation... the dependencies are injected into either
request or session, not directly into a client object. Different, but
still quite useful.
I implemented (more or less... tending towards less ;) this because it
seemed like most of my apps wanted to always have this or that object in
various scopes. It wasn't totally config-file driven but a combination
of config file which basically supplied factory class names that would
then do what I wanted.
This solution generally worked for me, but I sometimes found the
delocalization a bit magical: "Man, I'm looking at the code for this
action and I don't see ANYTHING relating to what I'm seeing in Real Life."
*poof*
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
