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