You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Cedric Dumoulin <ce...@s1.com> on 2000/11/13 14:26:59 UTC
Interfaces vs base classes
I would like to know why Struts uses base classes rather
than interfaces with default implementations.
As example, I am interested to know why ActionForm is an abstract
class rather than an Interface (as in previous Struts versions).
Could you explain me the reasons ?
For my point of view, it seem that using base classes
rather than interfaces close some doors in this case : With a base
class, you "have to" extends the class, which forbid any others classe
inheritances. But, an ActionForm is used to expose properties from, lets
say, business logic objects (BO). So, you must implement your action
form with a delegate of your BO. If later you modify your BO
(customization for a new client), you need to modify your action form.
This will not happen if your action form can extend the BO (or its data
representation), and use a delegate for the ActionForm interface. So,
why closing this possibility ? Do I miss something ?
Cedric
Re[2]: Interfaces vs base classes
Posted by Matthias Kerkhoff <ma...@BESToffers.de>.
Hi Cedric,
> Could you please give me pointers to this thread ?
Sorry, I should have done this in my previous mail.
08/23/2000 "Override auto-population feature of Struts (repost)?"
08/23/2000 "getting access to the HTTPSession from an ActionForm bean"
08/24/2000 "Save the ActionForm interface! (was ...HTTPSession...)"
There may have been more threads, that I have missed.
--
Matthias (mailto:make@BESToffers.de)
Re: Interfaces vs base classes
Posted by Cedric Dumoulin <ce...@s1.com>.
Hi Matthias,
I don't want to restart a thread on something that has already been discuss.
I have certainly miss something ;-)
Could you please give me pointers to this thread ?
Cedric
Matthias Kerkhoff wrote:
> Hi Cedric,
>
> > For my point of view, it seem that using base classes
> > rather than interfaces close some doors in this case : With a base
> > class, you "have to" extends the class, which forbid any others classe
> > inheritances. But, an ActionForm is used to expose properties from, lets
> > say, business logic objects (BO). So, you must implement your action
> > form with a delegate of your BO. If later you modify your BO
> > (customization for a new client), you need to modify your action form.
> > This will not happen if your action form can extend the BO (or its data
> > representation), and use a delegate for the ActionForm interface. So,
> > why closing this possibility ? Do I miss something ?
>
> I have the same problem and would prefer the more flexible solution
> that Sun has choosen for such situations. As an example, I would like
> to mention Tag/TagSupport or BeanInfo/SimpleBeanInfo.
> Having a mandatory interface and a optional base class leaves the
> decision to the developer.
> He/she can choose either
> - to implement the interface, if full flexibility is needed, or a base
> class already exists; or otherwise
> - to extend the default base class and minimize the own development efforts.
>
> However, there has been a long discussion some weeks ago on this list
> (or was it in Struts-Users?), if ActionForm should be a base class or
> an interface. It's probably not a good idea to restart this thread again.
>
> --
> Matthias (mailto:make@BESToffers.de)
Re: Interfaces vs base classes
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Palamadai Sriram wrote:
> Error : Iam not allowed to use Java script , hope that clarifies
>
Is this restriction due to management or technical issues in your environment,
or are you perceiving a limitation in Struts that prevents this?
Struts, in and of itself, does not care whether or not you use JavaScript for
certain client side validations. In fact, the form-based tags include event
handler attributes precisely so that you can define such validations. Indeed,
future versions of Struts may support the automatic generation of JavaScript
validation functions for common cases.
If you are considering using JavaScript, you should also be aware of the
following:
* Not every validation check can be done conveniently
in a JavaScript function. For example, it is not easy
to go ask a database whether or not a particular value
is already in use (and therefore not available).
* Even if you are using JavaScript for client side validations,
you should *always* check everything again on the server
side. You have no guarantees that the client who submitted
this request has JavaScript enabled, or even that they are
using a browser.
For server side validation, Struts supports the following functionality (in
1.0), prior to calling your action method:
* The form bean's reset() method is called, which allows you
to deal with things like checkboxes by resetting to default
values.
* The property setters are called to reflect all of the input values
submitted with this form.
* The validate() method of the form bean is called, which can
perform any desired checks, and return a set of error messages.
* If any errors are detected by the validate() method, Struts
returns control to the designated input form, *instead of*
calling your action class.
* If no errors are detected, the appropriate action class is
selected and the perform() method is executed.
Craig McClanahan
RE: Interfaces vs base classes
Posted by Palamadai Sriram <pa...@s1.com>.
Error : Iam not allowed to use Java script , hope that clarifies
-----Original Message-----
From: Palamadai Sriram [mailto:palamadai.sriram@s1.com]
Sent: Monday, November 13, 2000 12:45 PM
To: struts-dev@jakarta.apache.org
Subject: RE: Interfaces vs base classes
Hello Matthias,
Iam having a problem of major proportions here , would be very thankful if
you could help me out.
Iam trying to have validations for each individual JSP and not having to go
to the action class every time. Ideally I would like the validations to be
done on the JSP could use a bean on the JSP(automatically set the fields in
the bean) validate it by calling my validator class and pass to the next JSP
page.This way I call the action class only in the last JSP when I will
perform my Business logic and forward to the next jsp/virtual path. I am
allowed to use Java script and all the validation is for the Client Side
only.Any suggestions will be welcome.
Ram
-----Original Message-----
From: Matthias Kerkhoff [mailto:make@BESToffers.de]
Sent: Monday, November 13, 2000 9:36 AM
To: Cedric Dumoulin
Subject: Re: Interfaces vs base classes
Hi Cedric,
> For my point of view, it seem that using base classes
> rather than interfaces close some doors in this case : With a base
> class, you "have to" extends the class, which forbid any others classe
> inheritances. But, an ActionForm is used to expose properties from, lets
> say, business logic objects (BO). So, you must implement your action
> form with a delegate of your BO. If later you modify your BO
> (customization for a new client), you need to modify your action form.
> This will not happen if your action form can extend the BO (or its data
> representation), and use a delegate for the ActionForm interface. So,
> why closing this possibility ? Do I miss something ?
I have the same problem and would prefer the more flexible solution
that Sun has choosen for such situations. As an example, I would like
to mention Tag/TagSupport or BeanInfo/SimpleBeanInfo.
Having a mandatory interface and a optional base class leaves the
decision to the developer.
He/she can choose either
- to implement the interface, if full flexibility is needed, or a base
class already exists; or otherwise
- to extend the default base class and minimize the own development efforts.
However, there has been a long discussion some weeks ago on this list
(or was it in Struts-Users?), if ActionForm should be a base class or
an interface. It's probably not a good idea to restart this thread again.
--
Matthias (mailto:make@BESToffers.de)
RE: Interfaces vs base classes
Posted by Palamadai Sriram <pa...@s1.com>.
Hello Matthias,
Iam having a problem of major proportions here , would be very thankful if
you could help me out.
Iam trying to have validations for each individual JSP and not having to go
to the action class every time. Ideally I would like the validations to be
done on the JSP could use a bean on the JSP(automatically set the fields in
the bean) validate it by calling my validator class and pass to the next JSP
page.This way I call the action class only in the last JSP when I will
perform my Business logic and forward to the next jsp/virtual path. I am
allowed to use Java script and all the validation is for the Client Side
only.Any suggestions will be welcome.
Ram
-----Original Message-----
From: Matthias Kerkhoff [mailto:make@BESToffers.de]
Sent: Monday, November 13, 2000 9:36 AM
To: Cedric Dumoulin
Subject: Re: Interfaces vs base classes
Hi Cedric,
> For my point of view, it seem that using base classes
> rather than interfaces close some doors in this case : With a base
> class, you "have to" extends the class, which forbid any others classe
> inheritances. But, an ActionForm is used to expose properties from, lets
> say, business logic objects (BO). So, you must implement your action
> form with a delegate of your BO. If later you modify your BO
> (customization for a new client), you need to modify your action form.
> This will not happen if your action form can extend the BO (or its data
> representation), and use a delegate for the ActionForm interface. So,
> why closing this possibility ? Do I miss something ?
I have the same problem and would prefer the more flexible solution
that Sun has choosen for such situations. As an example, I would like
to mention Tag/TagSupport or BeanInfo/SimpleBeanInfo.
Having a mandatory interface and a optional base class leaves the
decision to the developer.
He/she can choose either
- to implement the interface, if full flexibility is needed, or a base
class already exists; or otherwise
- to extend the default base class and minimize the own development efforts.
However, there has been a long discussion some weeks ago on this list
(or was it in Struts-Users?), if ActionForm should be a base class or
an interface. It's probably not a good idea to restart this thread again.
--
Matthias (mailto:make@BESToffers.de)
RE: Interfaces vs base classes
Posted by Palamadai Sriram <pa...@s1.com>.
Iam having a problem of major proportions here , would be very thankful if
you could help me out.
Iam trying to have validations for each individual JSP and not having to go
to the action class every time. Ideally I would like the validations to be
done on the JSP could use a bean on the JSP(automatically set the fields in
the bean) validate it by calling my validator class and pass to the next JSP
page.This way I call the action class only in the last JSP when I will
perform my Business logic and forward to the next jsp/virtual path. I am
allowed to use Java script and all the validation is for the Client Side
only.Any suggestions will be welcome.
Ram
-----Original Message-----
From: Matthias Kerkhoff [mailto:make@BESToffers.de]
Sent: Monday, November 13, 2000 9:36 AM
To: Cedric Dumoulin
Subject: Re: Interfaces vs base classes
Hi Cedric,
> For my point of view, it seem that using base classes
> rather than interfaces close some doors in this case : With a base
> class, you "have to" extends the class, which forbid any others classe
> inheritances. But, an ActionForm is used to expose properties from, lets
> say, business logic objects (BO). So, you must implement your action
> form with a delegate of your BO. If later you modify your BO
> (customization for a new client), you need to modify your action form.
> This will not happen if your action form can extend the BO (or its data
> representation), and use a delegate for the ActionForm interface. So,
> why closing this possibility ? Do I miss something ?
I have the same problem and would prefer the more flexible solution
that Sun has choosen for such situations. As an example, I would like
to mention Tag/TagSupport or BeanInfo/SimpleBeanInfo.
Having a mandatory interface and a optional base class leaves the
decision to the developer.
He/she can choose either
- to implement the interface, if full flexibility is needed, or a base
class already exists; or otherwise
- to extend the default base class and minimize the own development efforts.
However, there has been a long discussion some weeks ago on this list
(or was it in Struts-Users?), if ActionForm should be a base class or
an interface. It's probably not a good idea to restart this thread again.
--
Matthias (mailto:make@BESToffers.de)
Re: Interfaces vs base classes
Posted by Matthias Kerkhoff <ma...@BESToffers.de>.
Hi Cedric,
> For my point of view, it seem that using base classes
> rather than interfaces close some doors in this case : With a base
> class, you "have to" extends the class, which forbid any others classe
> inheritances. But, an ActionForm is used to expose properties from, lets
> say, business logic objects (BO). So, you must implement your action
> form with a delegate of your BO. If later you modify your BO
> (customization for a new client), you need to modify your action form.
> This will not happen if your action form can extend the BO (or its data
> representation), and use a delegate for the ActionForm interface. So,
> why closing this possibility ? Do I miss something ?
I have the same problem and would prefer the more flexible solution
that Sun has choosen for such situations. As an example, I would like
to mention Tag/TagSupport or BeanInfo/SimpleBeanInfo.
Having a mandatory interface and a optional base class leaves the
decision to the developer.
He/she can choose either
- to implement the interface, if full flexibility is needed, or a base
class already exists; or otherwise
- to extend the default base class and minimize the own development efforts.
However, there has been a long discussion some weeks ago on this list
(or was it in Struts-Users?), if ActionForm should be a base class or
an interface. It's probably not a good idea to restart this thread again.
--
Matthias (mailto:make@BESToffers.de)
Re: Interfaces vs base classes
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Cedric Dumoulin wrote:
> I would like to know why Struts uses base classes rather
> than interfaces with default implementations.
>
> As example, I am interested to know why ActionForm is an abstract
> class rather than an Interface (as in previous Struts versions).
> Could you explain me the reasons ?
>
>From my perspective, there are a couple of reasons that ActionForm is
turning into a class instead of an interface:
* EXTENDABILITY. Adding a new method to an ActionForm interface
(in some future version of Struts) will cause any application's form
beans to become incompatible -- unless they happened to implement
the convenience base class that was provided. With ActionForm
as a class, the only beans that are incompatible are those who have
a method name clash.
* CORRECT USE. If ActionForm were an interface, you would be
tempted to use existing data beans as an ActionForm. IMHO,
ActionForm is part of the presentation layer (for reasons that have
been discussed on the mailing lists previously) and the provided
APIs should encourage using it that way.
>
> For my point of view, it seem that using base classes
> rather than interfaces close some doors in this case : With a base
> class, you "have to" extends the class, which forbid any others classe
> inheritances. But, an ActionForm is used to expose properties from, lets
> say, business logic objects (BO). So, you must implement your action
> form with a delegate of your BO. If later you modify your BO
> (customization for a new client), you need to modify your action form.
> This will not happen if your action form can extend the BO (or its data
> representation), and use a delegate for the ActionForm interface. So,
> why closing this possibility ? Do I miss something ?
>
Consider that your business object has property setters that match the form
fields (a very typical case). Do you have any internal validation in your
setters to, for example, disallow a null or zero-length value for a required
field? If you do, then this bean is *not* appropriate for use as an
ActionForm - because the API contract for an ActionForm is that it
faithfully represents the input that the user submitted (so that it can be
reproduced), whether or not that input is semantically valid.
There are additional problems with the fact that -- especially if you use
EJBs as your business objects -- you are starting transactions (and
potentially locking resources in the underlying database), when the user may
never come back. Applications will scale better if you don't start
initiating the database transactions until a semantically valid input has
been accepted.
>
> Cedric
Craig McClanahan