Handling Multipart forms (sort of Wizard)
Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep
RE: Handling Multipart forms (sort of Wizard)
Well I don't know if this is conventional, but what I've done is to add an attribute to the form, say 'action', and to add action as a hidden field in the form. Then assign it a different value on each form... in your case maybe 'education', 'experience' and 'general'. form:hidden property=action value=education/ Then in your validate() method check what the action field is set to and only validate the fields on that form. Simple. - Darryl -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 09:32 To: [EMAIL PROTECTED] Subject: Handling Multipart forms (sort of Wizard) Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep
RE: Handling Multipart forms (sort of Wizard)
Sandeep Let me try. See if the solution proposed makes sense as the techniques were discussed before. 1) Include a PageNumber attribute into your Form bean. In your JSP, store the PageNumber as a hidden attribute. In your form.validate() method, determine which page is passed then validate the appropriate fields. For this to work, you will need maintain your form bean in the session object (ie set the scope in your struts-config.xml file). 2) Create three form beans (ie one for each JSP) and create a mother bean that has all the attributes of the three form beans. In this case, each form beans can perform its validate method() and the form action class can copy each form properties to the mother bean using PropertyUtil.copyProperty method. Note you will need to store the mother bean into the session object. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 15:32 To: [EMAIL PROTECTED] Subject: Handling Multipart forms (sort of Wizard) Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep
RE: Handling Multipart forms (sort of Wizard)
Hi Suhas Good question. I missed out some steps for the second option. You will need to create three form actions to process each of the form beans. The mother bean is stored in the session and is accessed and updated in each action. Hence at the end of the logical process, the mother bean has all the values for your 3 forms. Hope it makes sense. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: suhas [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 16:13 To: [EMAIL PROTECTED] Subject: Re: Handling Multipart forms (sort of Wizard) In the below 2nd option - what is the need of the mother bean when u already have separate beans for each jsp Suhas - Original Message - From: Michael Mok [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 8:51 AM Subject: RE: Handling Multipart forms (sort of Wizard) Sandeep Let me try. See if the solution proposed makes sense as the techniques were discussed before. 1) Include a PageNumber attribute into your Form bean. In your JSP, store the PageNumber as a hidden attribute. In your form.validate() method, determine which page is passed then validate the appropriate fields. For this to work, you will need maintain your form bean in the session object (ie set the scope in your struts-config.xml file). 2) Create three form beans (ie one for each JSP) and create a mother bean that has all the attributes of the three form beans. In this case, each form beans can perform its validate method() and the form action class can copy each form properties to the mother bean using PropertyUtil.copyProperty method. Note you will need to store the mother bean into the session object. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 15:32 To: [EMAIL PROTECTED] Subject: Handling Multipart forms (sort of Wizard) Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: -- -- I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep
RE: Handling Multipart forms (sort of Wizard)
Michael, Regarding your proposed solution#2, design a mother form bean that contains three child form beans. in that case how the child form bean will be instantiated? and will these child form beans auto collect data submited by users? Rgds, Victor --- Michael Mok [EMAIL PROTECTED] wrote: Sandeep Let me try. See if the solution proposed makes sense as the techniques were discussed before. 1) Include a PageNumber attribute into your Form bean. In your JSP, store the PageNumber as a hidden attribute. In your form.validate() method, determine which page is passed then validate the appropriate fields. For this to work, you will need maintain your form bean in the session object (ie set the scope in your struts-config.xml file). 2) Create three form beans (ie one for each JSP) and create a mother bean that has all the attributes of the three form beans. In this case, each form beans can perform its validate method() and the form action class can copy each form properties to the mother bean using PropertyUtil.copyProperty method. Note you will need to store the mother bean into the session object. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 15:32 To: [EMAIL PROTECTED] Subject: Handling Multipart forms (sort of Wizard) Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep __ Do You Yahoo!? Yahoo! Greetings - Send dad a Father's Day Card! http://greetings.yahoo.com.sg/
RE: Handling Multipart forms (sort of Wizard)
I think you're making things far too complicated. Read the note I posted a little while ago. - Darryl -Original Message- From: Victor Chai [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 10:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Handling Multipart forms (sort of Wizard) Michael, Regarding your proposed solution#2, design a mother form bean that contains three child form beans. in that case how the child form bean will be instantiated? and will these child form beans auto collect data submited by users? Rgds, Victor --- Michael Mok [EMAIL PROTECTED] wrote: Sandeep Let me try. See if the solution proposed makes sense as the techniques were discussed before. 1) Include a PageNumber attribute into your Form bean. In your JSP, store the PageNumber as a hidden attribute. In your form.validate() method, determine which page is passed then validate the appropriate fields. For this to work, you will need maintain your form bean in the session object (ie set the scope in your struts-config.xml file). 2) Create three form beans (ie one for each JSP) and create a mother bean that has all the attributes of the three form beans. In this case, each form beans can perform its validate method() and the form action class can copy each form properties to the mother bean using PropertyUtil.copyProperty method. Note you will need to store the mother bean into the session object. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 15:32 To: [EMAIL PROTECTED] Subject: Handling Multipart forms (sort of Wizard) Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep __ Do You Yahoo!? Yahoo! Greetings - Send dad a Father's Day Card! http://greetings.yahoo.com.sg/
RE: Handling Multipart forms (sort of Wizard)
Hi Victor A high level sequence diagram fillform.html --- loadfirstpage.do --- firstpage.jsp firstpage.jsp -- savefirstpage.do -- loadsecondpage.do -- secondpage.jsp secondpage.jsp -- savesecondpage.do -- loadthirdpage.do -- thirdpage.jsp thirdpage.jsp -- savethirdpage.do. See my responses below. -Original Message- From: Victor Chai [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 16:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Handling Multipart forms (sort of Wizard) Michael, Regarding your proposed solution#2, design a mother form bean that contains three child form beans. in that case how the child form bean will be instantiated? STRUTS will initialise a form bean if the form bean is not initialised prior to calling your action.perform() method. and will these child form beans auto collect data submited by users? Yes, if you design one JSP page for each form bean. Rgds, Victor
RE: Handling Multipart forms (sort of Wizard)
Hi Michael, Thanks for the options you specified for handling this. After going thru the suggested options, I think the 2nd option is better. This is because, since it is a wizrd, so there is back and next buttons to correct the data in different JSPs before saving. If we need to handle this using child-mother beans then we need to keep child beans also in the session scope. This is because each child bean is associated with one form so to get the entered data after forwarding 2-3 pages , if we again want to come back to the 1'st page, data should be preserved. Although, we can do it by copying mother bean properties back in the child bean.. What say? - Sandeep Michael Mok [EMAIL PROTECTED] on 06/12/2001 03:48:01 PM Please respond to [EMAIL PROTECTED]; Please respond to [EMAIL PROTECTED] To: 'suhas' [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Sandeep Yawale/LTITLPUN) Subject: RE: Handling Multipart forms (sort of Wizard) Hi Suhas Good question. I missed out some steps for the second option. You will need to create three form actions to process each of the form beans. The mother bean is stored in the session and is accessed and updated in each action. Hence at the end of the logical process, the mother bean has all the values for your 3 forms. Hope it makes sense. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: suhas [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 16:13 To: [EMAIL PROTECTED] Subject: Re: Handling Multipart forms (sort of Wizard) In the below 2nd option - what is the need of the mother bean when u already have separate beans for each jsp Suhas - Original Message - From: Michael Mok [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 8:51 AM Subject: RE: Handling Multipart forms (sort of Wizard) Sandeep Let me try. See if the solution proposed makes sense as the techniques were discussed before. 1) Include a PageNumber attribute into your Form bean. In your JSP, store the PageNumber as a hidden attribute. In your form.validate() method, determine which page is passed then validate the appropriate fields. For this to work, you will need maintain your form bean in the session object (ie set the scope in your struts-config.xml file). 2) Create three form beans (ie one for each JSP) and create a mother bean that has all the attributes of the three form beans. In this case, each form beans can perform its validate method() and the form action class can copy each form properties to the mother bean using PropertyUtil.copyProperty method. Note you will need to store the mother bean into the session object. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 15:32 To: [EMAIL PROTECTED] Subject: Handling Multipart forms (sort of Wizard) Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: -- -- I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep
RE: Handling Multipart forms (sort of Wizard)
PROTECTED] on 12/06/2001 09:40:33 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Andrew Steady/Swindon01/Domino01/Kinesis) Subject: RE: Handling Multipart forms (sort of Wizard) Hi Michael, Thanks for the options you specified for handling this. After going thru the suggested options, I think the 2nd option is better. This is because, since it is a wizrd, so there is back and next buttons to correct the data in different JSPs before saving. If we need to handle this using child-mother beans then we need to keep child beans also in the session scope. This is because each child bean is associated with one form so to get the entered data after forwarding 2-3 pages , if we again want to come back to the 1'st page, data should be preserved. Although, we can do it by copying mother bean properties back in the child bean.. What say? - Sandeep Michael Mok [EMAIL PROTECTED] on 06/12/2001 03:48:01 PM Please respond to [EMAIL PROTECTED]; Please respond to [EMAIL PROTECTED] To: 'suhas' [EMAIL PROTECTED] cc: [EMAIL PROTECTED] (bcc: Sandeep Yawale/LTITLPUN) Subject: RE: Handling Multipart forms (sort of Wizard) Hi Suhas Good question. I missed out some steps for the second option. You will need to create three form actions to process each of the form beans. The mother bean is stored in the session and is accessed and updated in each action. Hence at the end of the logical process, the mother bean has all the values for your 3 forms. Hope it makes sense. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: suhas [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 16:13 To: [EMAIL PROTECTED] Subject: Re: Handling Multipart forms (sort of Wizard) In the below 2nd option - what is the need of the mother bean when u already have separate beans for each jsp Suhas - Original Message - From: Michael Mok [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 8:51 AM Subject: RE: Handling Multipart forms (sort of Wizard) Sandeep Let me try. See if the solution proposed makes sense as the techniques were discussed before. 1) Include a PageNumber attribute into your Form bean. In your JSP, store the PageNumber as a hidden attribute. In your form.validate() method, determine which page is passed then validate the appropriate fields. For this to work, you will need maintain your form bean in the session object (ie set the scope in your struts-config.xml file). 2) Create three form beans (ie one for each JSP) and create a mother bean that has all the attributes of the three form beans. In this case, each form beans can perform its validate method() and the form action class can copy each form properties to the mother bean using PropertyUtil.copyProperty method. Note you will need to store the mother bean into the session object. Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 15:32 To: [EMAIL PROTECTED] Subject: Handling Multipart forms (sort of Wizard) Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: -- -- I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep
Re: Handling Multipart forms (sort of Wizard)
I haven't tried this yet, but one way might be to setup an ActionMapping for each step in the Wizard, and set the parameter property for each. Struts passes the ActionMapping to validation, so you should be able to use mapping.getParameter() to tell where you are. You can then use this same technique within an Action, if you need to perform any processing between steps (like routing to a different step based on what they selected). action-mappings !-- Entry point -- action parameter=step0 path=/wizard/Start type=package.wizard name=wizardForm scope=session validate=false forward name=success path=/WEB-INF/jsp/wizard/Step1.jsp/ /action action-mappings !-- Step1 submits here -- action parameter=step1 path=/wizard/Step1 type=package.wizard name=wizardForm scope=session validate=true input=/WEB-INF/jsp/wizard/Step1.jsp forward name=success path=WEB-INF/jsp/wizard/Step2.jsp/ /action action-mappings !-- Step2 submits here -- action parameter=step2 path=/wizard/Step2 type=package.wizard name=wizardForm scope=session validate=true input=/WEB-INF/jsp/wizard/Step2.jsp !-- the package.wizard Action would check the form and choose one of these forwards -- forward name=rent path=/wizard/Step3/rent.do/ forward name=own path=/wizard/Step3/own.do/ /action in validate() String step = mapping.getParameter(); // ... handle validation for each step in Action String step = mapping.getParameter(); // .. analyze form, if needed, and route to next step -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ [EMAIL PROTECTED] wrote: Hello All, I am using mulipart forms for adding an employee information. In this I have 3 forms namely, emplEducation, emplExperience, emplGeneral in separate JSPs. In this case, I am using only one form bean for all these JSPs and only one action class. My problem is how to validate the Form bean after each page submission: I know the validation can be done in the form bean using validate() method or in the action class But, if user filled emplEducation form and press Next, to go to emplExperience, how do I validate only those form bean fields related to emplEducation and not the others till they are entered by user?? Is there any straight forward strategy for handling this?? - Sandeep
RE: Handling Multipart forms (sort of Wizard)
This sounds like a very elegant though sophisticated design. Any way you could post some diagrams or something? I don't know, GIF's of object models etc. Or is there a URL you could direct us to? Just curious because I wasn't smart enough to understand everything from your description. - Darryl -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 11:34 To: [EMAIL PROTECTED] Cc: Ben Radford Subject: RE: Handling Multipart forms (sort of Wizard) Hi, Our solution, using struts, is a mutli-page and multi-channel solution. It works on the principle of page numbers and has only one action per wizard regardless of the number of pages involved. There is a base class form which has a validate method that can validate any form in a generic method, validating only the fields on the current page, and after completion of the wizard does a finalValidate check to make sure nothing remained unvalidated (this is necassary due to the dynamic way in which the page by page validation is executed). In our system we have a data dictionary most fields represent a field in the data dictionary - this link to the data dictionary which performs the validation for that particular type of field e.g. a PostCode validator. The data dictionary also returns the possible values for fields which are of a select variety - the labels are then looked up based on the current language, the field type and the value. If a field is not representing a data dictionary member a localValidator must be written in the form object name e.g. validatePostCode. CrossFieldValidations are executed in a similar manner and we have added functionality to ensure crossFieldValidations are run at the correct time (one of the tough bits!). The base class Form (which extends ActionForm) is then subclassed, one per wizard, the member field objects are defined in the initialise method, the fields have objects which have attributes and methods as necassary to complete the functionality. The getters and setters in the wizard form fetch the correct field from the collection and set/get the value to return to the struts tag libraries/other code. Each form is then sublassed once per channel (Wap, HTML and iDTV - all of which we have working). The subclass specifies to the field objects which page each field is on for that particular channel, this enables the validation to work correctly and also means business validation errors from the EJB container after wizard completion and submission can be directed to the correct page for display. The sublassed channel specific form can add extra fields and specify which page they lie on (or set a field to be internal). An example of this is that the base class of a transaction may contain a single date field. On the Web channel this is actually 3 fields (day, month, year) on the Wap channel this is just a selection of today/tomorrow etc. As each page is submitted a method on the channel specific sublass called mapData is called - in the Web channel this maps the 3 fields into the 1 date field, on the Wap channel it maps todays date or tomorrows date into the base class single date field. The validation is then run and any errors are displayed by including the error tag to the base class date field (although a mapError method could be called to map it to the year field in the web channel etc.). When a form is prepopulated from stored records before the user begins to complete it a mapInitialData method is called - in the web channel this would pre-populate the day/month/year fields based upon the date value in the base class - the reverse of mapData. We have many more obscure mappings as well as simple date ones. There is an ActionMapping per channel for each transaction and as well as having keys for when the Action has completed such as success, home, error also have entries, one per page of the wizard like this forward name=page2 path=/forms/transactionA/Web/page2.jsp. Using this we have host of methods on the form (although these might be better located on an ActionMapping sublass) which are all used in a completely generic and centralised way (in the ActionClass we created by extending the Action class) page flow is controlled using methods such as getCurrentPage, getNextPage, isLastPage, getNextPageActionForward, etc etc. The benefits of this design are that no matter what channel is running, you can be sure that a transaction will always be validated in one way and be represented by one form. If the channel has a different way of completing the same form, but to the same end, all you need to do is model the differences in a subclass. This means extra channels can be added *extremely* quickly, as all that needs to be created is an ActionMapping and small Form subclass per transaction. Another benefit is that all page flow is controlled only by data from the ActionMappings and only via generic methods in base classes - so there will never be any hunting around looking
RE: Handling Multipart forms (sort of Wizard)
Hi, I'm working on the documentation now and feel it would only be fair to contribute some of these diagrams back to the struts community. It will probably take me a couple of days to get it sorted though. I hate documentation, grg. Cheers, Andy S p.s. I think it has more to do with my style of writing than your lack of smartness - did I mention that I hate documentation? [EMAIL PROTECTED] on 12/06/2001 11:09:16 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Andrew Steady/Swindon01/Domino01/Kinesis) Subject: RE: Handling Multipart forms (sort of Wizard) This sounds like a very elegant though sophisticated design. Any way you could post some diagrams or something? I don't know, GIF's of object models etc. Or is there a URL you could direct us to? Just curious because I wasn't smart enough to understand everything from your description. - Darryl -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 11:34 To: [EMAIL PROTECTED] Cc: Ben Radford Subject: RE: Handling Multipart forms (sort of Wizard) Hi, Our solution, using struts, is a mutli-page and multi-channel solution. It works on the principle of page numbers and has only one action per wizard regardless of the number of pages involved. There is a base class form which has a validate method that can validate any form in a generic method, validating only the fields on the current page, and after completion of the wizard does a finalValidate check to make sure nothing remained unvalidated (this is necassary due to the dynamic way in which the page by page validation is executed). In our system we have a data dictionary most fields represent a field in the data dictionary - this link to the data dictionary which performs the validation for that particular type of field e.g. a PostCode validator. The data dictionary also returns the possible values for fields which are of a select variety - the labels are then looked up based on the current language, the field type and the value. If a field is not representing a data dictionary member a localValidator must be written in the form object name e.g. validatePostCode. CrossFieldValidations are executed in a similar manner and we have added functionality to ensure crossFieldValidations are run at the correct time (one of the tough bits!). The base class Form (which extends ActionForm) is then subclassed, one per wizard, the member field objects are defined in the initialise method, the fields have objects which have attributes and methods as necassary to complete the functionality. The getters and setters in the wizard form fetch the correct field from the collection and set/get the value to return to the struts tag libraries/other code. Each form is then sublassed once per channel (Wap, HTML and iDTV - all of which we have working). The subclass specifies to the field objects which page each field is on for that particular channel, this enables the validation to work correctly and also means business validation errors from the EJB container after wizard completion and submission can be directed to the correct page for display. The sublassed channel specific form can add extra fields and specify which page they lie on (or set a field to be internal). An example of this is that the base class of a transaction may contain a single date field. On the Web channel this is actually 3 fields (day, month, year) on the Wap channel this is just a selection of today/tomorrow etc. As each page is submitted a method on the channel specific sublass called mapData is called - in the Web channel this maps the 3 fields into the 1 date field, on the Wap channel it maps todays date or tomorrows date into the base class single date field. The validation is then run and any errors are displayed by including the error tag to the base class date field (although a mapError method could be called to map it to the year field in the web channel etc.). When a form is prepopulated from stored records before the user begins to complete it a mapInitialData method is called - in the web channel this would pre-populate the day/month/year fields based upon the date value in the base class - the reverse of mapData. We have many more obscure mappings as well as simple date ones. There is an ActionMapping per channel for each transaction and as well as having keys for when the Action has completed such as success, home, error also have entries, one per page of the wizard like this forward name=page2 path=/forms/transactionA/Web/page2.jsp. Using this we have host of methods on the form (although these might be better located on an ActionMapping sublass) which are all used in a completely generic and centralised way (in the ActionClass we created by extending the Action class) page flow is controlled using methods such as getCurrentPage, getNextPage, isLastPage, getNextPageActionForward, etc etc. The benefits of this design are that no matter what channel is running
RE: Handling Multipart forms (sort of Wizard)
Thanks, that'll be great. Look forward to the post. Ditto on documentation... one of those necessary evils in life you know, whisperlike women./whisper ;) -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 12:09 To: [EMAIL PROTECTED] Subject: RE: Handling Multipart forms (sort of Wizard) Hi, I'm working on the documentation now and feel it would only be fair to contribute some of these diagrams back to the struts community. It will probably take me a couple of days to get it sorted though. I hate documentation, grg. Cheers, Andy S p.s. I think it has more to do with my style of writing than your lack of smartness - did I mention that I hate documentation? [EMAIL PROTECTED] on 12/06/2001 11:09:16 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Andrew Steady/Swindon01/Domino01/Kinesis) Subject: RE: Handling Multipart forms (sort of Wizard) This sounds like a very elegant though sophisticated design. Any way you could post some diagrams or something? I don't know, GIF's of object models etc. Or is there a URL you could direct us to? Just curious because I wasn't smart enough to understand everything from your description. - Darryl -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 11:34 To: [EMAIL PROTECTED] Cc: Ben Radford Subject: RE: Handling Multipart forms (sort of Wizard) Hi, Our solution, using struts, is a mutli-page and multi-channel solution. It works on the principle of page numbers and has only one action per wizard regardless of the number of pages involved. There is a base class form which has a validate method that can validate any form in a generic method, validating only the fields on the current page, and after completion of the wizard does a finalValidate check to make sure nothing remained unvalidated (this is necassary due to the dynamic way in which the page by page validation is executed). In our system we have a data dictionary most fields represent a field in the data dictionary - this link to the data dictionary which performs the validation for that particular type of field e.g. a PostCode validator. The data dictionary also returns the possible values for fields which are of a select variety - the labels are then looked up based on the current language, the field type and the value. If a field is not representing a data dictionary member a localValidator must be written in the form object name e.g. validatePostCode. CrossFieldValidations are executed in a similar manner and we have added functionality to ensure crossFieldValidations are run at the correct time (one of the tough bits!). The base class Form (which extends ActionForm) is then subclassed, one per wizard, the member field objects are defined in the initialise method, the fields have objects which have attributes and methods as necassary to complete the functionality. The getters and setters in the wizard form fetch the correct field from the collection and set/get the value to return to the struts tag libraries/other code. Each form is then sublassed once per channel (Wap, HTML and iDTV - all of which we have working). The subclass specifies to the field objects which page each field is on for that particular channel, this enables the validation to work correctly and also means business validation errors from the EJB container after wizard completion and submission can be directed to the correct page for display. The sublassed channel specific form can add extra fields and specify which page they lie on (or set a field to be internal). An example of this is that the base class of a transaction may contain a single date field. On the Web channel this is actually 3 fields (day, month, year) on the Wap channel this is just a selection of today/tomorrow etc. As each page is submitted a method on the channel specific sublass called mapData is called - in the Web channel this maps the 3 fields into the 1 date field, on the Wap channel it maps todays date or tomorrows date into the base class single date field. The validation is then run and any errors are displayed by including the error tag to the base class date field (although a mapError method could be called to map it to the year field in the web channel etc.). When a form is prepopulated from stored records before the user begins to complete it a mapInitialData method is called - in the web channel this would pre-populate the day/month/year fields based upon the date value in the base class - the reverse of mapData. We have many more obscure mappings as well as simple date ones. There is an ActionMapping per channel for each transaction and as well as having keys for when the Action has completed such as success, home, error also have entries, one per page of the wizard like this forward name=page2 path=/forms/transactionA/Web/page2.jsp. Using this we have host of methods on the form (although these might be better located
Re: Handling Multipart forms (sort of Wizard)
Darryl, you need to get away from the pc a little more ;^ - Original Message - From: Darryl Pentz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 6:19 AM Subject: RE: Handling Multipart forms (sort of Wizard) Thanks, that'll be great. Look forward to the post. Ditto on documentation... one of those necessary evils in life you know, whisperlike women./whisper ;) -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 12:09 To: [EMAIL PROTECTED] Subject: RE: Handling Multipart forms (sort of Wizard) Hi, I'm working on the documentation now and feel it would only be fair to contribute some of these diagrams back to the struts community. It will probably take me a couple of days to get it sorted though. I hate documentation, grg. Cheers, Andy S p.s. I think it has more to do with my style of writing than your lack of smartness - did I mention that I hate documentation? [EMAIL PROTECTED] on 12/06/2001 11:09:16 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Andrew Steady/Swindon01/Domino01/Kinesis) Subject: RE: Handling Multipart forms (sort of Wizard) This sounds like a very elegant though sophisticated design. Any way you could post some diagrams or something? I don't know, GIF's of object models etc. Or is there a URL you could direct us to? Just curious because I wasn't smart enough to understand everything from your description. - Darryl -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 11:34 To: [EMAIL PROTECTED] Cc: Ben Radford Subject: RE: Handling Multipart forms (sort of Wizard) Hi, Our solution, using struts, is a mutli-page and multi-channel solution. It works on the principle of page numbers and has only one action per wizard regardless of the number of pages involved. There is a base class form which has a validate method that can validate any form in a generic method, validating only the fields on the current page, and after completion of the wizard does a finalValidate check to make sure nothing remained unvalidated (this is necassary due to the dynamic way in which the page by page validation is executed). In our system we have a data dictionary most fields represent a field in the data dictionary - this link to the data dictionary which performs the validation for that particular type of field e.g. a PostCode validator. The data dictionary also returns the possible values for fields which are of a select variety - the labels are then looked up based on the current language, the field type and the value. If a field is not representing a data dictionary member a localValidator must be written in the form object name e.g. validatePostCode. CrossFieldValidations are executed in a similar manner and we have added functionality to ensure crossFieldValidations are run at the correct time (one of the tough bits!). The base class Form (which extends ActionForm) is then subclassed, one per wizard, the member field objects are defined in the initialise method, the fields have objects which have attributes and methods as necassary to complete the functionality. The getters and setters in the wizard form fetch the correct field from the collection and set/get the value to return to the struts tag libraries/other code. Each form is then sublassed once per channel (Wap, HTML and iDTV - all of which we have working). The subclass specifies to the field objects which page each field is on for that particular channel, this enables the validation to work correctly and also means business validation errors from the EJB container after wizard completion and submission can be directed to the correct page for display. The sublassed channel specific form can add extra fields and specify which page they lie on (or set a field to be internal). An example of this is that the base class of a transaction may contain a single date field. On the Web channel this is actually 3 fields (day, month, year) on the Wap channel this is just a selection of today/tomorrow etc. As each page is submitted a method on the channel specific sublass called mapData is called - in the Web channel this maps the 3 fields into the 1 date field, on the Wap channel it maps todays date or tomorrows date into the base class single date field. The validation is then run and any errors are displayed by including the error tag to the base class date field (although a mapError method could be called to map it to the year field in the web channel etc.). When a form is prepopulated from stored records before the user begins to complete it a mapInitialData method is called - in the web channel this would pre-populate the day/month/year fields based upon the date value in the base class - the reverse of mapData. We have many more obscure mappings as well as simple date ones. There is an ActionMapping per channel
RE: Handling Multipart forms (sort of Wizard)
Jonathan, I don't think you understand... they're NECESSARY... but evil if you disagree, you're obviously not married. :) Sorry, now I'm clogging up the list. Just joking naturally, for all the ladies on the list. - Darryl -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 14:50 To: [EMAIL PROTECTED] Subject: Re: Handling Multipart forms (sort of Wizard) Darryl, you need to get away from the pc a little more ;^ - Original Message - From: Darryl Pentz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 6:19 AM Subject: RE: Handling Multipart forms (sort of Wizard) Thanks, that'll be great. Look forward to the post. Ditto on documentation... one of those necessary evils in life you know, whisperlike women./whisper ;) -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 12:09 To: [EMAIL PROTECTED] Subject: RE: Handling Multipart forms (sort of Wizard) Hi, I'm working on the documentation now and feel it would only be fair to contribute some of these diagrams back to the struts community. It will probably take me a couple of days to get it sorted though. I hate documentation, grg. Cheers, Andy S p.s. I think it has more to do with my style of writing than your lack of smartness - did I mention that I hate documentation? [EMAIL PROTECTED] on 12/06/2001 11:09:16 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Andrew Steady/Swindon01/Domino01/Kinesis) Subject: RE: Handling Multipart forms (sort of Wizard) This sounds like a very elegant though sophisticated design. Any way you could post some diagrams or something? I don't know, GIF's of object models etc. Or is there a URL you could direct us to? Just curious because I wasn't smart enough to understand everything from your description. - Darryl -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 11:34 To: [EMAIL PROTECTED] Cc: Ben Radford Subject: RE: Handling Multipart forms (sort of Wizard) Hi, Our solution, using struts, is a mutli-page and multi-channel solution. It works on the principle of page numbers and has only one action per wizard regardless of the number of pages involved. There is a base class form which has a validate method that can validate any form in a generic method, validating only the fields on the current page, and after completion of the wizard does a finalValidate check to make sure nothing remained unvalidated (this is necassary due to the dynamic way in which the page by page validation is executed). In our system we have a data dictionary most fields represent a field in the data dictionary - this link to the data dictionary which performs the validation for that particular type of field e.g. a PostCode validator. The data dictionary also returns the possible values for fields which are of a select variety - the labels are then looked up based on the current language, the field type and the value. If a field is not representing a data dictionary member a localValidator must be written in the form object name e.g. validatePostCode. CrossFieldValidations are executed in a similar manner and we have added functionality to ensure crossFieldValidations are run at the correct time (one of the tough bits!). The base class Form (which extends ActionForm) is then subclassed, one per wizard, the member field objects are defined in the initialise method, the fields have objects which have attributes and methods as necassary to complete the functionality. The getters and setters in the wizard form fetch the correct field from the collection and set/get the value to return to the struts tag libraries/other code. Each form is then sublassed once per channel (Wap, HTML and iDTV - all of which we have working). The subclass specifies to the field objects which page each field is on for that particular channel, this enables the validation to work correctly and also means business validation errors from the EJB container after wizard completion and submission can be directed to the correct page for display. The sublassed channel specific form can add extra fields and specify which page they lie on (or set a field to be internal). An example of this is that the base class of a transaction may contain a single date field. On the Web channel this is actually 3 fields (day, month, year) on the Wap channel this is just a selection of today/tomorrow etc. As each page is submitted a method on the channel specific sublass called mapData is called - in the Web channel this maps the 3 fields into the 1 date field, on the Wap channel it maps todays date or tomorrows date into the base class single date field. The validation is then run and any errors are displayed by including the error tag to the base class date field (although a mapError method could be called to map
Re: Handling Multipart forms (sort of Wizard)
I am married. Its ME WHO IS EVIL ;^ - Original Message - From: Darryl Pentz [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Jonathan Asbell [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 8:53 AM Subject: RE: Handling Multipart forms (sort of Wizard) Jonathan, I don't think you understand... they're NECESSARY... but evil if you disagree, you're obviously not married. :) Sorry, now I'm clogging up the list. Just joking naturally, for all the ladies on the list. - Darryl -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 14:50 To: [EMAIL PROTECTED] Subject: Re: Handling Multipart forms (sort of Wizard) Darryl, you need to get away from the pc a little more ;^ - Original Message - From: Darryl Pentz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 12, 2001 6:19 AM Subject: RE: Handling Multipart forms (sort of Wizard) Thanks, that'll be great. Look forward to the post. Ditto on documentation... one of those necessary evils in life you know, whisperlike women./whisper ;) -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 12:09 To: [EMAIL PROTECTED] Subject: RE: Handling Multipart forms (sort of Wizard) Hi, I'm working on the documentation now and feel it would only be fair to contribute some of these diagrams back to the struts community. It will probably take me a couple of days to get it sorted though. I hate documentation, grg. Cheers, Andy S p.s. I think it has more to do with my style of writing than your lack of smartness - did I mention that I hate documentation? [EMAIL PROTECTED] on 12/06/2001 11:09:16 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Andrew Steady/Swindon01/Domino01/Kinesis) Subject: RE: Handling Multipart forms (sort of Wizard) This sounds like a very elegant though sophisticated design. Any way you could post some diagrams or something? I don't know, GIF's of object models etc. Or is there a URL you could direct us to? Just curious because I wasn't smart enough to understand everything from your description. - Darryl -Original Message- From: Andrew Steady [mailto:[EMAIL PROTECTED]] Sent: 12 June 2001 11:34 To: [EMAIL PROTECTED] Cc: Ben Radford Subject: RE: Handling Multipart forms (sort of Wizard) Hi, Our solution, using struts, is a mutli-page and multi-channel solution. It works on the principle of page numbers and has only one action per wizard regardless of the number of pages involved. There is a base class form which has a validate method that can validate any form in a generic method, validating only the fields on the current page, and after completion of the wizard does a finalValidate check to make sure nothing remained unvalidated (this is necassary due to the dynamic way in which the page by page validation is executed). In our system we have a data dictionary most fields represent a field in the data dictionary - this link to the data dictionary which performs the validation for that particular type of field e.g. a PostCode validator. The data dictionary also returns the possible values for fields which are of a select variety - the labels are then looked up based on the current language, the field type and the value. If a field is not representing a data dictionary member a localValidator must be written in the form object name e.g. validatePostCode. CrossFieldValidations are executed in a similar manner and we have added functionality to ensure crossFieldValidations are run at the correct time (one of the tough bits!). The base class Form (which extends ActionForm) is then subclassed, one per wizard, the member field objects are defined in the initialise method, the fields have objects which have attributes and methods as necassary to complete the functionality. The getters and setters in the wizard form fetch the correct field from the collection and set/get the value to return to the struts tag libraries/other code. Each form is then sublassed once per channel (Wap, HTML and iDTV - all of which we have working). The subclass specifies to the field objects which page each field is on for that particular channel, this enables the validation to work correctly and also means business validation errors from the EJB container after wizard completion and submission can be directed to the correct page for display. The sublassed channel specific form can add extra fields and specify which page they lie on (or set a field to be internal). An example of this is that the base class of a transaction may contain a single date field. On the Web channel this is actually 3 fields (day, month, year) on the Wap channel this is just a selection of today/tomorrow etc. As each page is submitted a method on the channel specific
