Is the resolution of this discussion that I shouldn't ever do something like this:
public interface Employee extends Serializable
public class EmployeeObject implements Employee
public class EmployeeForm extends ActionForm implements Employee
public ActionForward execute(.....) throws ......
{
EmployeeForm empForm = (EmployeeForm) form;
Employee employee = new EmployeeObject();
BeanUtils.copyProperties(empForm, employee);
// persist employee object
}
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tue 1/14/2003 10:04 PM
To: Struts Users Mailing List
Cc:
Subject: Re: changing ActionForm to be a Java interface
A few intermixed comments and replies.
On Tue, 14 Jan 2003, Dan Jacobs wrote:
> Date: Tue, 14 Jan 2003 22:49:34 -0500
> From: Dan Jacobs <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: changing ActionForm to be a Java interface
>
> Hi Craig,
>
> Thanks for your prompt response. My comments are mixed in below.
>
> Craig R. McClanahan wrote:
>
> >
> >On Tue, 14 Jan 2003, Dan Jacobs wrote:
> >
> >>Date: Tue, 14 Jan 2003 20:36:19 -0500
> >>From: Dan Jacobs <[EMAIL PROTECTED]>
> >>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >>To: [EMAIL PROTECTED]
> >>Subject: changing ActionForm to be a Java interface
> >>
> >> Hi all,
> >>
> >>I know this is very late in the 1.1 game to change things very much, but
> >>I'd like to make an API change request.
> >>
> >>Currently, ActionForm is defined as a class rather than as an interface.
> >> The problem with that is that it doesn't allow other kinds of objects
> >>to act as ActionForms.
> >>
> >
> >It's not going to happen -- absolutely positively not for 1.1, and
> >(pretty much) over my dead body for any subsequent 1.x release. I'm
> >taking advantage of the single inheritance restriction of Java to make it
> >more difficult for most people to do things that they should not do.
> >
> Well, I understand your point, but I don't agree with the idea that an
> enabling technology should prevent competent and conscientious engineers
> from being competent and conscientious, just because other folks might
> display incompetence. They probably will anyway.
>
> >
> >A bit of history -- up to Struts 0.5, ActionForm was indeed an interface.
> >The problem is that *way* too many people tried to use the ActionForm as a
> >value object, which was wrong for two reasons:
> >
> I remember that, and I was puzzled about the change at the time. I feel
> pretty strongly about the sanctity of model objects myself (enough to
> choose it as my company name), and I completely agree that ActionForms
> should never be confused with models. On the other hand, it would be
> handy if they could at least help out with the rendering. :-)
>
> >
> >* It encouraged you to make the property types match
> > the underlying business tier instead of Strings,
> > which violated one of the primary
> > purposes for ActionForms in the first place (the ability
> > to reproduce invalid input, which is a fundamental
> > user expectation).
> >
> I suppose this is the point that a lot of Struts users don't fully take
> to heart, and I agree it's one of the things that Struts does very well
> that other systems do very poorly. But I doubt that providing an
> interface along with a default implementation would do much to
> strengthen or weaken people's understanding of the concept.
>
Oh, but it did ... that was the primary reason for the change.
Consider a model object that has an int field. The idea of using
ActionForm as a value object encourages you to make the property type
of the form bean an int instead of a String -- or at least it did to lots
and lots of early Struts users, who then couldn't figure out why their
redisplay stopped working.
The same thing happens if you've got existing VO classes (with native data
types) and wanted to just say "implements ActionForm" so that they could
use the existing class as a form bean.
This happened way too many times for my comfort zone. So, as a framework
architect, I had to act somewhat like a parent -- "no, you cannot do that,
and it's for your own good." :-)
> >
> >* It tied your business tier to Struts APIs, which meant
> > you had to import things like servlet.jar into places
> > that it has no business at all.
> >
> >Because it was obvious that people were going to misuse the Struts APIs in
> >this way, I switched ActionForm to being a class instead. People still
> >try to misuse it :-), but most of them find it easier to do what they
> >really should do in the first place -- use plain old JavaBeans (POJOs) for
> >value objects.
> >
> I'm kind of a roles and responsibilities guy. In my experience, things
> don't get chronically misused when those two are done just right. In
> this case, I'm not sure what could be done to improve it though.
If we had the luxury of experienced users, this probably would not have
been a problem. My problem is that Struts is very popular -- particularly
among folks who are new to both the web tier and to Java. And, quite
often, they have only minimal knowledge of what object oriented
programming is about (many come with experience in JavaScript and/or VB,
which support some level of O-O concepts, but are rife with examples of
misuse as well).
>
> >
> >>In particular, I want to be able to use JPlates objects (see
> >>http://www.jplates.com ) as ActionForms, since that would allow me to
> >>encapsulate the full behavior of a form in the object, instead of just
> >>having a place to put the data. I can already use JPlates in place of
> >>JSPs for rendering (which is wonderful!), but I'd have a more consistent
> >>solution if I could use JPlates objects for my ActionForms as well.
> >>
> >
> >Can you use the "nested" facilities to make this integration happen one
> >layer deeper? In other words, you can define an ActionForm (or
> >DynaActionForm) with a single nested property that points at your JPlates
> >objects, or otherwise wraps them?
> >
> >I also find it interesting that the JPlates docs think that their
> >technology will work just fine with Struts, without making this kind of a
> >change ...
> >
> Well, like I said, I use JPlates easily in place of JSPs for rendering,
> because JPlates comes with a dispatching servlet similar to yours,
> allowing JPlates to be addressed using URLs just like JSPs. So in that
> way, JPlates works with Struts just as well as Velocity.
>
That was the design goal. What people resist, though, is the notion that
form beans belong to the framework, not to the view technology :-).
> For ActionForms, though, I can only use JPlates instances by delegation
> from an anstance of an ActionForm subclass, which is ok, but not idea.
> I'd rather be able to implement IActionForm from a JPlates class and
> delegate to an ActionForm if necessary.
>
If you intermix the presentation capabilities of a JPlates object and the
data storage capabilities of an ActionForm, doesn't that mean you would
have to give up the (currently supported) capability to use the same form
bean for more than one view page?
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
<<winmail.dat>>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
