Michael Jouravlev wrote the following on 7/6/2005 12:26 PM:
So, you use action forms both for input and output. This is great.
Change the scope to "session", throw in some methods, and you get
yourself a backing bean. This is what it should be.
Well, not really. I should be able to use a POJO/ValueObject not tied to
Struts packages. A true backing bean could be used on the backend and
front interchangeably. Sure, if I wanted to tie my entire backend to
Struts I could be passing around the ActionForm everywhere, but I don't
really like doing that (the whole seperation thing again:).
I don't think so. Both action form and action class belong to
web/presentation layer, so it does not make a difference for me where
to put my code. If, instead of having two classes, Struts had only one
class like Webwork, in which action can be stateful, then you would
not have any doubts, would you? So consider action class and action
form as part of what could be one class.
I have considered this, and again this is another reason I consider the
ActionForm the ugly duckling of Struts:)
4) Since the ActionForm is used to capture user inputted data, it seems
against the grain to have the ActionForm itself populating a state that
the user wants to edit.
I don't have this feeling, but I am not suggesting a new universal
rule to access persistence layer from action form. I am merely saying
that if it works, why not?
One of the reasons is I'm not sure (like I mentioned below) how you
reuse this ActionForm under different situations... I often use the same
ActionForm in many diffrent cicumstances. I wouldn't want it always
being populated (the "add" was just one example) so you'd need a
mechanism to decide when and when not to call the populate and, not only
that, but what gets populated might need to change based on what the
ActionForm is being used for. For example, you might have a generic
UserForm (name and ID - for simplicity)- this form might sometimes be
used for dealing with Accounting users or sometimes HR Users. In order
to resuse this form in many different circumstances you'd have to have a
bunch of conditional logic in your ActionForm. I find it cleaner to
avoid that logic. I find it cleaner to bind that userForm to different
ActionMappings and thus the resulting Action takes care of knowing what
to do, vs putting all the responsibility on the ActionForm knowing how
to populate itself.
Um, author of original email did not provide any further information
on whether this form is used for 'add' too. I supposed, that it was
used for editing existing object, and for redisplaying entered data if
it is incorrect. To redisplay invalid user data it must not be
overwritten by pre-loaded data, thus reset() seems as simple and easy
way out, though you may think that it is simple and dirty way out ;)
Well, he didn't state he needed it for an "add" but I think an
ActionForm should be flexible enough to support it. (I doubt you'd make
a POJO that could be used in 'one way'.
In regard to "To redisplay invalid user data it must not be overwritten
by pre-loaded data, thus reset() seems as simple and easy way out..", I
must be confused on what you see happening that I don't. I don't use the
reset to pre-populate the form data and never have a problem with
anything being over-ridden when valiation fails (There is the problem of
request scoped forms that have lists on the page that need to be reset,
but that's another topic:).. and I wrote the solution I like
here..http://www.reumann.net/struts/articles/request_lists.jsp ).
The simplification of this approach is using of dispatch action and
redirecting from it to itself. Commands like 'create', 'edit', 'view'
are dispatched to handlers, which load or create an object, then
handlers redirect to the same action, which displays whatever is in
the form. See details here:
http://struts.sourceforge.net/strutsdialogs/crudaction.html
All CRUD operations are neatly provided by one class, but of course it
should be backed by an action form, which does the dirty work ;)
Guess I'm too old skool, I like the dirty work called from my Action
dispatch (CRUD) methods. So I might have...
setUpForEdit(...) {
Employee emp = service.getMeEmployee(someID);
PropertyUtils.copyProperties( (EmployeeActionForm)form, emp );
//...
}
edit(..) {
Employee emp = new Employee();
PropertyUtils.copyProperties( emp, (EmployeeActionForm)form );
service.updateEmployeee( emp );
//...
}
add(..)
seems pretty clean to me and his been doing the job quite effectively.
I would rather tell the new person, use Struts Dialogs, this is so
much simpler than to invent everything yourself, which you have to do
becuase Struts is so basic.
I'll have to check out Struts Dialog sometime.
Which is why I developed my library, so newbies
can save efforts creating UI. Why would not you take a look at it? But
it may seem a little unorthodox for you at first ;)
Sounds good. I'm not a complete stick-in-the-mud, I'm open to different
ideas.
Good discussion, now I have to do some work:)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
