Okay, from the FAQ:

   * Both the |/editRegistration| and |/saveRegistration| actions use
     the same form bean.
   * When the |/editRegistration| action is entered, Struts will have
     pre-created an empty form bean instance, and passed it to the
     |execute()| method. The setup action is free to preconfigure the
     values that will be displayed when the form is rendered, simply by
     setting the corresponding form bean properties.
   * When the setup action completes configuring the properties of the
     form bean, it should return an |ActionForm| that points at the
     page which will display this form. If you are using the Struts JSP
     tag library, the |action| attribute on your <html:form> tag will
     be set to |/saveRegistration| in order for the form to be
     submitted to the processing action.

-----
The only way for my form to pre-populate from the 'editRegistration' page is to set my html:form action to the 'editRegistration'. However, I can't submit to 'saveRegistration' then!


Maybe I'm doing this incorrectly: the first page loads the data from the DB, and then forwards to a JSP, which displays that data using HTML:FORM. Upon submit, it should go to the second page, which saves the data. Am I missing something?

- Nic.

My struts-config:
<action path="/userEdit"
type="com.racquetclub.action.UserEditAction" name="user">
<forward name="display" path="/Users/UserEdit.jsp"/>
</action>
<action path="/userUpdate"
type="com.racquetclub.action.UserUpdateAction"
name="user">
<forward name="success" path="/Users/displayUsers.jsp"/>
</action>




Jesse Clark wrote:

Joel,

Here is a short description from the FAQ that starts to describe the alternative that Jack mentioned below: http://struts.apache.org/faqs/newbie.html#prepopulate.

This approach basically means that you end up with two actions per form/jsp which will increase your maintenance work a little but it provides clean entry points into the work flow and clearly illustrates what responsibilities an action has by its naming scheme. In the FAQ their example actions are called /editFoo and /saveFoo but when I use this approach I usually name my action DisplayFooAction and ProcessFooAction where Foo indicates the primary function of the jsp/form that these actions handle, i.e DisplayEditProfileAction and ProcessEditProfileAction for my editProfile.jsp and EditProfileForm.

Then the DisplayFooAction is responsible for gathering the data needed to prepopulate the Form from the business service, populating the Form and placing it in scope for the jsp. I request that a business service prepare the View necessary for the Foo page and then either, populate the Form from POJOs in the view or use collections from the view directly in the jsp to populate drop-down lists & etc. The Form is already available to you in the Action because it is declared in the action mapping for both the DisplayFoo and ProcessFoo actions.

Just to qualify my advice, I am still relatively new to this myself and this approach seemed like the simplest way to go for now, but I kinda feel like having 2 actions per page might end up being too much extra baggage and there might be other implications of which I am not yet aware.

Hope this helps, anyhow,

-Jesse


Schuster Joel M Contr ESC/NDC wrote:

Ok, I understand. I'm just really trying to understand this.

http://resonus.net/wiki/uploads/strutsq.jpg

Here's a link to a little picture that I put together because that happens
to be how I think.


Please tell me what I'm missing in my understanding of what struts is all
about.
1. Standard login process.
a) request to website from browser, we redirect to the login.jsp via
an action or forward.
b) Submit is clicked and system encapsulates the data from the
request into a form which is then given to the action.execute which
c) then determines if the values are correct and forwards to the
right place depending.


2. Now, If I want to have the main menu simply go from one screen to another
then I have a link. But the second screen needs to be 'populated' (for lack
of a better word) with data.
3. To do it the struts 'way' is to link to an action instead. This action
fills the framework provided form (because it is defined in the mapping) and
forwards to the edit screen.


4. The update action uses the same form which is now filled with changed
values from the jsp.

--- I keep getting the impression that I've missed something in my
understanding of how and more importantly why --- I want to understand, not
just do things blindly.


I understand that the ActionForm is intended to STORE and VALIDATE
USER-ENTERED data (off the struts page)... but then there seems to be a big
hole in the functionality of struts. How do you get to the point of having a
person select inventory and purchase it if you can't first display that
inventory?


- Joel


-----Original Message-----
From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 12:02 PM
To: Struts Users Mailing List
Subject: Re: Correct Prepopulate Method


I may be wrong, Joel, but I think Joe and Hubert are thinking of you
instantiating a form that is not listed in your action mapping.  You
can readily figure out why they think this way.  You can, as you seem
to want to, avoid this complication that actually sort of takes you
out of the reason for the Struts framework by having your ActionForm
encompass the data in both the "pre-Action" and "post-Action" JSP/HTML
forms.

Jack


On Fri, 11 Mar 2005 11:57:33 -0700, Schuster Joel M Contr ESC/NDC
<[EMAIL PROTECTED]> wrote:


I've been looking into the RequestProcessor and RequestUtils classes and

it


looks like as long as my action mapping specifies a name, even on a setup
action goes through the same process... calling createActionForm().


Thus there is no reason to go through my own ModuleConfig again.


-----Original Message----- From: Hubert Rabago [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 10:13 AM To: Struts Users Mailing List Subject: Re: Correct Prepopulate Method

On Fri, 11 Mar 2005 09:50:59 -0700, Schuster Joel M Contr ESC/NDC
<[EMAIL PROTECTED]> wrote:


I'm not sure I understand the need for the moduleConfig and such for
creating the DynaActionForm.

The FormBeanConfig object provides access to the createActionForm() method. That's the object you actually need. You can get to that through the ModuleConfig for the current module.



If we've specified the name="myForm" in the action config then shouldn't

the


form coming into the execute be and empty version of my form? Thus

allowing:


    execute( ActionMapping mapping, ActionForm form ... {
           DynaActionForm myForm = (DynaActionForm) form;
    }

(As a matter of fact I know this works :))


This is true when you're in the action to which the form was submitted. In the example I gave, this would be the /submitForm action. In a setup action, this mapping may not be available or may be referring to a different form altogether.



Also, using

request.getSession().setAttribute("myForm", myForm);

is exactly the issue. Although it then allows the follow up jsp to gain
access to the formbean during form(html) creation it doesn't determine

how


then to remove the form from the session except by explicit removal in

the


final update/submit action unless you config the submit as request scope
only. But that doesn't actually remove the formbean from the session

scope


that we added it into... it just copies it into the request scope too.

--- so back to sqare one. :P

You can specify which scope you want the form bean to be in (read the bottom of my prev email). Struts uses session scope by default, which is why that's what I mentioned first. You can choose to use request scope.

hth,
Hubert



-----Original Message-----
From: Hubert Rabago [mailto:[EMAIL PROTECTED]
Sent: Friday, March 11, 2005 9:36 AM
To: Struts Users Mailing List
Subject: Re: Correct Prepopulate Method

You would usually do prepopulation in a setup form.  Which scope you
place the form in depends on how you configure the action that the
form will be submitted to.  For example, if you have "/showPage.do"
and "/submitForm.do", where submitForm is configured as:

<action path="/submitForm" name="myForm" ...>....</action>

Then in the action for showPage, you'd:

   ModuleConfig moduleConfig =
ModuleUtils.getInstance().getModuleConfig(request);
   FormBeanConfig formBeanConfig =
moduleConfig.findFormBeanConfig("myForm");
   DynaActionForm myForm = (DynaActionForm)
formBeanConfig.createActionForm(getServlet());

   myForm.set("propName",propValue);
   request.getSession().setAttribute("myForm", myForm);

If you want to use request scope, change /submitForm to:
<action path="/submitForm" name="myForm"

scope="request"...>....</action>


then in showPage:
   request.setAttribute("myForm", myForm);

Hubert


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to