See, now it gets interesting because debate starts :)
(I'm already thinking this should probably be moved to the dev list by
the way)...
Paul Benedict wrote:
(1) POJO for forms
Agreed, this would be very nice, and I know it has been discussed before.
(2) Stubbing of abstract attributes for framework
implementation like Tapestry.
This is a new concept to me, I'll have to investigate this further.
Consequently, no comment at this time :)
(3) The use of native data types in forms without
worrying of validation.
This one I actually *disagree* with... My thinking now is that an
ActionForm, whether POJO or not, should only contain Strings. I believe
it is a misuse of an ActionForm otherwise and promotes the idea that an
ActionForm can (or even worse, should) be passed to business delegates.
I mean, if my ActionForm has native types and all the conversions are
handled for me automaticlly, doesn't seem a little redundant to have a
DTO that is passed from an Action to a business delegate? I think many
would think so and get into bad habits (habits I myself had to break
myself of by the way!).
(4) Action methods being part of the POJO.
I'm not sure how I feel about this yet... this has also been talked
about, recently as I recall... I do agree there is some bemefit to this,
but I'm not sure I like the mixing of essential DTOs (which is what an
ActionForm is in the end) and Actions. You might be able to convince me
on this one, but I don't think I'm with you on it yet :)
Just imagine how cool it would be to have something
like:
public class MyActionForm {
// stub out properties
public abstract String getFirstName();
public abstract String getLastName();
public abstract int getAge();
public void save(ActionContext ac) {
// save form here
}
public void edit(ActionContext ac) {
// edit form here
}
public void bluegrass(ActionContext ac) {
// do something else here
}
}
The ActionContext is something that has definitely been discussed, and I
am completely for that. I absolutely think an Action should no longer
be accepting HTTP-specific objects. This was the model my own framework
took some years ago, and it is one of the very few things that I
actually missed when I moved to Struts.
I notice you take an approach much like a DispatchAction. I seem to be
in the minority on this, but I dislike DispatchActions. I believe they
largely run contrary to general object-oriented design (I realize
however there is a rational argument that says it very much *IS* inline
with OO thinking). I would favor an approach that allowed you to do
like the code you posted does, but doesn't force you into it in any way,
much like there is nothing forcing you to use a DispatchAction today.
In this example, all four things happen:
(1) The object is a POJO and (3) uses native data
types. If any conversion failure happens, it is
considered an automatic validation error.
I'm not sure how I feel about *any* conversion error being a validation
error... I think there may be scenarios where the conversion error
should be handled differently than a validation error. In either case,
this might be something to think about more.
(3) Action methods are now part of the action form
itself. Here I used the Struts 1.3 method of having
the Chain-of-command object be the only thing passed
in, which should contain references to any other web
object you need to complete this request. I believe
JSF does something similar, and why not imitate this
good idea? Besides, I think the Struts Roadmap has a
similar idea planned for 1.5???
Agreed. However, an interesting question is what thet ActionContext
should be... is it just a Map or is it a real bean? Do I have to do
ae.get("request") or do I do ae.getRequest()? The former is more
flexible and won't require changes when new objects are added, but the
later is more obvious and in a sense self-documenting (much like the
debate about whether it is better to pass generic Maps and such to
business delegates or true beans? I used to think Maps were better, now
I believe beans are).
Thanks guys.
Excellent food for thought!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
