Thanks!
On Sunday, Aug 24, 2003, at 06:38 Canada/Eastern, Adam Hardy wrote:
Ah, I see I missed out a bit of the logic.
My action class has a part that is executed for every action mapping, which fetches the necessary related data, such as dropdown lists (but not the actual object's properties).
What else the action does is dependent on the result of a bit of logic which is executed after the mandatory processing mentioned above.
I'm having problems describing it, perhaps it's easier to understand just looking at the xml:
<action path="/secure/startSectionInsert"
type="org.blacksail.linklib.section.SectionAction"
name="sectionForm"
scope="request"
validate="false"
parameter="blank"
roles="user">
<set-property property="secure" value="false"/>
<forward name="finished" path=".section"/>
</action>
<action path="/secure/startSectionUpdate"
type="org.blacksail.linklib.section.SectionAction"
name="sectionForm"
scope="request"
validate="false"
parameter="display"
roles="user">
<set-property property="secure" value="false"/>
<forward name="finished" path=".section"/>
</action>
<action path="/secure/sectionUpdate"
type="org.blacksail.linklib.section.SectionAction"
name="sectionForm"
scope="request"
validate="true"
parameter="save"
input="/secure/sectionValidateFailed.do"
roles="user">
<set-property property="secure" value="false"/>
<forward name="failed" path=".section"/>
<forward name="display" path="/secure/startSectionUpdate.do"/>
<forward name="finished" path="/secure/library.do" redirect="true"/>
</action>
<action path="/secure/sectionValidateFailed"
type="org.blacksail.linklib.section.SectionAction"
name="sectionForm"
scope="request"
parameter="finished"
roles="user">
<set-property property="secure" value="false"/>
<forward name="finished" path=".section"/>
</action>
Both insert and update submit to update. The last mapping there just does the mandatory getting the required dropdown lists.
HTH Adam
On 08/24/2003 02:13 AM ll wrote:Thanks for the reply. So in your save action your form input is the action that sets up the form. Meaning that in your struts-config for the save action you have input="/edit.do" or input="/add.do"...? Which one do you choose?
Also, as I understand it, this can only work if the action doesn't set any of the form fields. Do your actions set any form fields? If not, then I guess you can always use the "add" action. But in my case the add action sets some values (for example to preselect a default item in an options list), and of course the edit action also sets values (it looks up the values from the database). So after submitting, if the validation fails, the form field values are changed, they are not what the user just typed.
Or am I misunderstanding something?
Thanks...
On Saturday, Aug 23, 2003, at 13:42 Canada/Eastern, Adam Hardy wrote:Hi II
I use your method 1. My add and edit actions use the same JSP and both submit to the same save action. In my add, I set the id to 0, so on save, it knows that this is an add and not an edit.
I had to make a decision not to allow 0s as ids in the database. Possibly I could have used a negative number instead, as long as it validates.
Adam
On 08/23/2003 07:29 PM ll wrote:
Here's my problem: I have a form page that uses some request-scoped attributes for some things it shows on the page (other than the form field data). I always access the page through an action which sets up the attributes. But if validation fails when I submit the form, then those request attributes no longer exist because the input forwards to the jsp page without going through the action again.
Two possible solutions:
1. On the "save" action, use input="/person/add" so that when validation fails control is forwarded back through the action, which can then set up the request attributes again.
- problem: I use the same page from an "edit" action, which takes a "person id" parameter and pre-fills the form. If I do it this way I will need two "save" actions, one that uses the "edit" page as the input and one that uses the "add" page as the input. Then the form can't be shared, because I the submit action will need to change depending on whether it is an add or an edit.
2. Store the attributes in the session instead of the request.
- problem: if the user has two browser windows open to the same form then the values displayed in the page could be wrong because they are shared
- problem: these attributes won't get removed later from the request (without a lot of work on my part)
Has anyone else encountered this problem? How do most people do this?
Thanks!
This is roughly what my struts-config setup looks like:
<action path="/person/add"
type="mypackage.PersonAction"
name="PersonalInfoForm"
scope="request"
validate="false"
parameter="personalInfoFormBlank">
<forward name="continue" path="/WEB-INF/docs/jsp/person/personalInfoForm.jsp"/> </action>
<action path="/person/edit"
type="mypackage.PersonAction"
name="PersonalInfoForm"
scope="request"
validate="false"
parameter="personalInfoFormFilled">
<forward name="continue" path="/WEB-INF/docs/jsp/person/personalInfoForm.jsp"/> </action>
<action path="/person/savePersonalInfo"
type="mypackage.PersonAction"
name="PersonalInfoForm"
scope="request"
input="/WEB-INF/docs/jsp/person/personalInfoForm.jsp"
parameter="personalInfoFormSubmit">
<forward name="continue" path="/app/main"/>
</action>
-------------------------------------------------------------------- -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9
--------------------------------------------------------------------- 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]
-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9
--------------------------------------------------------------------- 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]
