On Thu, 3 May 2001, Open Source wrote:

> Hi All,
> 
> I had previously posted a mail about prepopulating the
> form before it is presented to the user.
> 
> My take on this is :
> 
> 1.ActionForm will have a method called 
> init(HttpServletRequest req).
> In this init method we can use any request parameters
> to initilize the form the very first time like this
> 
>     public void init(ActionMapping mapping ,
> HttpServletRequest request)
> {
>           if (! initialized) {
>              doInit(mapping,request);
>              initialized = true;
>           }
> }
> doInit() will be app specific method for prepopulating
> the form before presenting it to user.
> 
> 2.Action Servlet will need an extra line to accomodate
> this.
> In the processPopulate method the last line would be 
> formInstance.init(mapping,request)
> 
> Does this sound reasonable to folks ?
> Or am I being a moron and there is some other way of
> acheving this ?
> 

While this technique could work, I tend to prefer a different approach,
based on the philosophy that pre-populating a form requires business
logic.

Consider the approach used in the example application, when you are on the
registration.jsp page and you want to edit one of the subscriptions.  What
happens is:

* The hyperlink goes to the /editSubscription action,
  passing the primary key information as request parameters.

* The /editSubscription action looks up the corresponding
  subscription in the database (and returns an error if this
  fails, which is tough to do in the init method of a form bean).

* The /editSubscription action instantiates a form bean,
  populates its values from the underlying database information,
  and places it in the appropriate scope.

* The /editSubscription action forwards to the "subscription.jsp"
  page.

* The "subscription.jsp" page finds the form bean pre-populated with
  the relevant information for the selected subscription.

This technique also keeps the form beans themselves simpler -- they don't
have to know how to read their own information from the database, or
access the appropriate EJBs, or whatever.  They stick to their purpose in
life, which is to be the server-side representation of the input fields on
a form.

> Your suggestions are welcome.
> 
> Srikanth
> 

Craig McClanahan

Reply via email to