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,
> > <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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>

Reply via email to