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,
> <whisper>like 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, grgrrrr.
>
> 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,
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 for hidden directives. Also all validation routines are generic
and
> centralised. It also means there is only one Form instantiated (although
it
> is several subclasses down). Also there is only one ActionClass created
per
> transaction.
> All forms live in Session scope which might prove problematic as we move
to
> production from solution centre work.
> I hope some of these ideas might help some of you and that I've expressed
> them in a remotely comprehensible manner!
> Cheers,
> Andy S
>
>
>
>
>
> [EMAIL 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
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
