struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <co...@Bspark.com>
Subject RE: Multi-page form
Date Tue, 10 Oct 2000 21:51:54 GMT
I think I have to agree. If you have ActionForm and also ActionFormBase,
then you have the option of either inheriting from the base class (easier,
and preferable), or in the case where you already have your own class, you
can implement ActionBase and delegate to an ActionFormBase Instance, e.g.

public class MyForm extends MyBaseClass implements ActionForm {
  ActionBase ab;
  MyForm() {
    ab = new ActionBase();
  }
  // implement ActionForm methods here and delegate to ActionBase instance
  ...
  ...
  ...
}

_BUT_ I have the feeling this would break should there be any code added in
ActionBase which did reflection on its own, 'this' instance. The simple
solution to this is for it is to always use a getForm() method to get the
base bean instance it should be working on, e.g., ActionFormBase has a new
constructor
  public ActionFormBase(ActionForm form) {
    this.form = form;
  }
and new method
  ActionForm getForm() { return form == null ? this : form; }



> -----Original Message-----
> From: Mike La Budde [mailto:mike.labudde@irista.com]
> Sent: October 10, 2000 2:45 PM
> To: struts-user@jakarta.apache.org
> Subject: Re: Multi-page form
> 
> 
> So, like its cousin before it, ActionForm will become a (base) class 
> instead of an interface.
> 
> For what it's worth, I prefer leaving both as interfaces and 
> providing 
> ActionBase and ActionFormBase for people to inherit from 
> should they choose 
> to. Doing it this way facilitates allowing people to plug in 
> existing code 
> a little bit easier. That is, one could simply implement the 
> interface in 
> an existing class and add the required method(s). Rather than 
> being forced 
> to create a new class and using an instance of the existing class to 
> delegate the work to...
> 
> Mike
> 
> At 10/10/2000 10:12 AM -0700, Craig R. McClanahan wrote:
> >Jason Kitchen wrote:
> >
> > > > On the other hand, I would also like to have access to the 
> > HttpServletRequest in
> > > > the validate method, in order to have access to other 
> parameters in 
> > the request,
> > > > or, more important, in the session. For example, the 
> validate method 
> > could
> > > > retrieve the locale of the current user in his session 
> and validate 
> > dates,
> > > > currencies, etc. in a locale-dependent way.
> > > >
> > > > Craig, is it something you plan to offer in a future release?
> > >
> >
> >The current design I am experimenting with gives the 
> validate() method 
> >access to the
> >controller servlet, the mapping that requested this bean 
> (because you 
> >might be using the
> >same bean in more than one action), and the incoming 
> request.  This seems 
> >to cover all
> >the information needs I could think of.
> >
> >
> > > > >
> > > > > May be some modifications are required to the API in 
> order to support
> > > > > this ?
> > >
> >
> >Yah, one big one ... ActionForm is going to become a class 
> instead of an 
> >interface.  But
> >then you gain the nice ability to have some default 
> functionality -- for 
> >example, you
> >don't need a new class for a ValidatingActionBean any more; 
> you just skip 
> >overriding the
> >default validate() method which always returns "everything is OK".
> >
> >Craig
> >
> >====================
> >See you at ApacheCon Europe <http://www.apachecon.com>!
> >Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
> >Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
> >                                     Applications to Tomcat
> 

Mime
View raw message