Return-Path: 
 <struts-user-return-14677-apmail-jakarta-struts-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-struts-user-archive@jakarta.apache.org
Received: (qmail 3708 invoked by uid 500); 5 Aug 2001 21:33:54 -0000
Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: struts-user@jakarta.apache.org
list-help: <mailto:struts-user-help@jakarta.apache.org>
list-unsubscribe: <mailto:struts-user-unsubscribe@jakarta.apache.org>
list-post: <mailto:struts-user@jakarta.apache.org>
Delivered-To: mailing list struts-user@jakarta.apache.org
Received: (qmail 3696 invoked from network); 5 Aug 2001 21:33:54 -0000
Received: from h32.sny.collab.net (HELO icarus.apache.org) (64.208.42.42)
  by h31.sny.collab.net with SMTP; 5 Aug 2001 21:33:54 -0000
Received: (qmail 26723 invoked by uid 1059); 5 Aug 2001 21:32:41 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 5 Aug 2001 21:32:41 -0000
Date: Sun, 5 Aug 2001 14:32:41 -0700 (PDT)
From: "Craig R. McClanahan" <craigmcc@apache.org>
X-Sender: craigmcc@localhost
To: "'struts-user@jakarta.apache.org'" <struts-user@jakarta.apache.org>
Subject: Re: processPopulate() call configurable?
In-Reply-To: <411EA40BC162D211B92B0008C7B1D2B3078AC0D4@arbmdex.arbitron.com>
Message-ID: <Pine.BSF.4.21.0108051428100.22712-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Rating: localhost 1.6.2 0/1000/N
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N



On Wed, 1 Aug 2001, Kapila, Ranjit wrote:

> Hi,
> 
> In the ActionServlet.process() method, the processPopulate() method is
> always called. Is there any way to set some request attribute etc so
> that the processPopulate call is configurable.
> 

If you don't want processPopulate() to be called, just omit the form bean
from your <action> element.

> The underlying problem is that if I prefill my form, all the values are
> overwritten by the Request objects current parameter values.
> 
> I this something that other people have run into? Any work around?
> 

If your case is what I'm thinking it is, you probably want to consider
using different actions for prepopulating (and then displaying) a form,
versus accepting (and processing) the form submit.

Consider in the struts-example application what happens when you select
the "Edit your registration profile" option from the main menu:

* This link goes to the "/editRegistration" action, which
* Prepopulates the form bean, and
* Forwards to the "/registration.jsp" page to display it with
  values from the "database".
* Then, the form is submitted to the "/saveRegistration" action,
  which validates the input (returning on any errors) or does
  the appropriate database action.

> Thanks,
> 
> Ranjit
> 
> 

Craig