You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Sean Moore <se...@mindspring.com> on 2000/10/10 05:01:18 UTC
Multi-page form
I also am very interested in the multipage "form".
a quote from the old user manual reads:
"Struts encourages you to define a single ActionForm bean that contains
properties for all of the fields, no matter which page the field is
actually displayed on. Likewise, the various pages of the same form
should all be submitted to the same Action Class. If you follow these
suggestions, the page designers can rearrange the fields among the
various pages, with no changes required to the processing logic in
most cases."
What attracted me was the ability for designers to take my
extra long one page form and turn it into as many pages as
needed for normal people and not change any application logic.
I have created a ActionForm called MultipageForm with all of the
variables.
I have created one Action called MultipageAction.
I like only having one Action and only one ActionForm.
My first sticking point is how do I validate the variables
on just the submited page before moving to the next page?
If my designers are moving things all around on
different pages then how do I know which variable is on
which page and when to validate it?
Can someone point me in the right direction?
When I get this working I would be glad to submit it as an
example.
Thanks,
Sean
Re: Multi-page form
Posted by Robert Leland <Ro...@freetocreate.org>.
> >
> > For what it's worth, I prefer leaving both as interfaces and providing
> > ActionBase and ActionFormBase for people to inherit from should they choose
> > to.
>
> Believe me, I wish this were a reasonable path ... but it appears to me that it
> is not.
> Consider the fact that, in the future, we want to enhance our notion of what an
> ActionForm does with some new optional functionality. For a concrete example,
> consider the desire to add a validate() method on a ValidatingActionForm that
> takes additional arguments to provide context information.
Absolutely, there are other reasonable path. It is called 'Delegation'. I posted
this yesterday on the struts-dev group about delegation.
If interested see mailto:struts-dev-get_769@jakarta.apache.org
An interface is not absolutely required. That is exactly how Sun got there self in
all
sorts of trouble when they designed AWT in Java 1.0, They uses Inheritance to extend
their classes. When AWT shipped with Java 1.0 it was generally regarded as one of the
worst piece of code around. Then they started working with the people at Borland
and redesigned AWT to use delegation for their next version of AWT so by version 1.2
it was considered one of the best most extensible designs around, and they did it
with delegation.
I just went to google and did a search for "design patterm" delegation.
Here is one example:
A quote from O'Reilly's JDBC and Java: Chapter 9 Persistance
(It look like entire chapter is on line)
"You will use two key design patterns to support the separation of business logic
from persistence logic: the memento pattern and delegation."
It can be found at :http://www.oreilly.com/catalog/jdbc2/chapter/ch09.html
Re: Multi-page form
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Mike La Budde wrote:
> So, like its cousin before it, ActionForm will become a (base) class
> instead of an interface.
>
>
> For what it's worth, I prefer leaving both as interfaces and providing
> ActionBase and ActionFormBase for people to inherit from should they choose
> to.
Believe me, I wish this were a reasonable path ... but it appears to me that it
is not.
Consider the fact that, in the future, we want to enhance our notion of what an
ActionForm does with some new optional functionality. For a concrete example,
consider the desire to add a validate() method on a ValidatingActionForm that
takes additional arguments to provide context information.
If ActionForm is a class, you can add a new method to ActionForm and provide
reasonable defaults, without breaking any existing ActionForm beans unless they
happen to already have a method with the same signature.
If ActionForm is an interface, we have just broken every single ActionForm bean
ever written by anyone in the entire world -- until they update every single such
bean (and big apps are going to have *lots* of them), they cannot upgrade to the
new version of Struts that uses the new functionality.
A very similar situation is happening with the JSP 1.2 spec -- a new method
(resetCustomAttributes) is being added to the Tag interface. Most people
(including me in Struts :-) build their tags on top of TagSupport -- a
convenience base class equivalent in purpose to ActionFormBase -- and are immune
to this change. But anyone who builds their beans by "implements Tag" instead is
stuck until the add the new method.
One might argue that, well, everyone is going to just "extends ActionFormBase"
anyway. If so, then why have both in the first place :-).
> Doing it this way facilitates allowing people to plug in existing code
> a little bit easier. That is, one could simply implement the interface in
> an existing class and add the required method(s). Rather than being forced
> to create a new class and using an instance of the existing class to
> delegate the work to...
>
That was the original reason that ActionForm was an interface.
However, I discovered that it encourages people to do the "wrong" thing (IMHO),
by adding "implements ActionForm" to their data layer objects or EJBs, instead of
creating new beans. This causes problems because the user request is not
necessarily semantically correct (that is, your data layer bean might reject
invalid property settings), and you will not be able to faithfully reproduce the
input values last entered by the user (which is the whole point of an ActionForm
bean).
Additionally, you can have problems if the user leaves part way through an update
without completing it. Many data layer objects are designed to start locking
things in the database when you start updating them. Now you've got a
half-completed update to get rid of, (usually you can do a ROLLBACK but there's a
performance cost of throwing away all that work) versus simply throwing away the
ActionForm bean for the form that the user did not finish.
I've come to believe that we really should want separate ActionForm beans, even
though most or all of the properties are the same. Think of ActionForm beans as
part of the View layer of MVC (where data layer beans are Model), and it will
make more sense why they are different.
>
> Mike
>
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Re: Multi-page form
Posted by Mike La Budde <mi...@irista.com>.
So, like its cousin before it, ActionForm will become a (base) class
instead of an interface.
For what it's worth, I prefer leaving both as interfaces and providing
ActionBase and ActionFormBase for people to inherit from should they choose
to. Doing it this way facilitates allowing people to plug in existing code
a little bit easier. That is, one could simply implement the interface in
an existing class and add the required method(s). Rather than being forced
to create a new class and using an instance of the existing class to
delegate the work to...
Mike
At 10/10/2000 10:12 AM -0700, Craig R. McClanahan wrote:
>Jason Kitchen wrote:
>
> > > On the other hand, I would also like to have access to the
> HttpServletRequest in
> > > the validate method, in order to have access to other parameters in
> the request,
> > > or, more important, in the session. For example, the validate method
> could
> > > retrieve the locale of the current user in his session and validate
> dates,
> > > currencies, etc. in a locale-dependent way.
> > >
> > > Craig, is it something you plan to offer in a future release?
> >
>
>The current design I am experimenting with gives the validate() method
>access to the
>controller servlet, the mapping that requested this bean (because you
>might be using the
>same bean in more than one action), and the incoming request. This seems
>to cover all
>the information needs I could think of.
>
>
> > > >
> > > > May be some modifications are required to the API in order to support
> > > > this ?
> >
>
>Yah, one big one ... ActionForm is going to become a class instead of an
>interface. But
>then you gain the nice ability to have some default functionality -- for
>example, you
>don't need a new class for a ValidatingActionBean any more; you just skip
>overriding the
>default validate() method which always returns "everything is OK".
>
>Craig
>
>====================
>See you at ApacheCon Europe <http://www.apachecon.com>!
>Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
>Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
> Applications to Tomcat
Re: Multi-page form
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Jason Kitchen wrote:
> > On the other hand, I would also like to have access to the HttpServletRequest in
> > the validate method, in order to have access to other parameters in the request,
> > or, more important, in the session. For example, the validate method could
> > retrieve the locale of the current user in his session and validate dates,
> > currencies, etc. in a locale-dependent way.
> >
> > Craig, is it something you plan to offer in a future release?
>
The current design I am experimenting with gives the validate() method access to the
controller servlet, the mapping that requested this bean (because you might be using the
same bean in more than one action), and the incoming request. This seems to cover all
the information needs I could think of.
> > >
> > > May be some modifications are required to the API in order to support
> > > this ?
>
Yah, one big one ... ActionForm is going to become a class instead of an interface. But
then you gain the nice ability to have some default functionality -- for example, you
don't need a new class for a ValidatingActionBean any more; you just skip overriding the
default validate() method which always returns "everything is OK".
Craig
====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00): Sun Technical Briefing
Session T06 (24-Oct 14h00-15h00): Migrating Apache JServ
Applications to Tomcat
Invalid struts-config_1_0.dtd
Posted by Robert Leland <Ro...@freetocreate.org>.
When I load up the struts-config.xml using XML Spy
I get the message
Invalid
http://jakarta.apache.org/struts/dtds/struts-config_1_0.dtd
When I validate that file I get:
Element "CData" is undefined
-Rob
--
Rob Leland Robert@freetocreate.org (+01-202-544-0533)
CGH Technologies
FAA ATA 200 Lab
Re: Multi-page form
Posted by Mike Papper <mp...@geocities.com>.
This email is regarding use of checkboxes in forms AND an issue with
setXXX methods in forms.
1) I suspect that an unchecked box is not handled correctly and
2) if I have a POST variable but no corresponding SetXXX method in the
Form class I get an exception.
Lets see, the logic flow seems to be (I use POST, but it could be GET as
well):
1) the XXForm class reads the POST variables and reads all the "set"
methods in its class.
2) It then sets all member variables within the Form from the POST
parameters
In my experience there are two problems:
1) it does not read non-existant checkboxes in the POST so it cannot
set the corresponding Form member variable how can we do this?
Shouldn't struts do this automagically for us (if struts set all SetXXX
methods that took a boolean parameter automatically to false, it would
not work with multiple forms, so the checkbox tag should also generate a
hidden variable that says that "no" checkbox was returned)
2) if there is a POST variable but no corresponding Form SetXXX method it
throws an exception. It would be nicer if struts emited a warning or
ignored the situation.
Has anyone else encountered these 2 problems?
When is it "safe" to trash my "alpha" structs version (mid August) and
get a 1.0 release? Does it exist yet? After apacheCon?
Mike Papper
mpapp@geocities.com
--------------------------------
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 10/10/2000, 1:42:22 PM, Sean Moore <se...@mindspring.com> wrote
regarding Re: Multi-page form:
> > Jason Kitchen wrote:
> > I still think you're missing the point - maybe I didn't explain myself
clearly.
> > The solution you provide above means that each time you move a field from
> > "step 1 form" to "step 2 form" or vice-versa you need to modify the
correct
> > "partialValidate" method. What I would like to do is to be able to move
fields
> > to another form with no code impact (other than JSP). I think that this
is what
> > the struts designers intended (comments from the struts developers ?) but
> > the validations are preventing the relaization of this goal.
> >
> Thanks Jason - that is exactly what I am trying to do.
> Maybe I am missing it but I have not heard a solution that does not
> involve a framework change??
> But Jason mentions this proposed modification
> > In addition I think that this is easily achievable with a few
modifications to the
> > struts framework:
> >
> > - Change the ValidatingActionForm interface - the signature to the
validate() method
> > becomes: public String[] validate(HttpServletRequest request);
> >
> > - In ActionServlet.processValidate() we need to pass the
HttpServletRequest object
> > as a parameter when we call the validate method.
> I guess after having the HttpServletRequest you can go thru all of the
> arguments that were submitted and then select the ones to validate.
> This is kind of what struts is already doing for you
> by setting all of the variables in the bean.
> I guess I was hoping for something a little more cleaner. I
> Just not sure what?
> Am I misunderstanding the solution the modification will allow
> Thanks,
> Sean
Re: Multi-page form
Posted by Jason Kitchen <ja...@s1.com>.
Sean Moore wrote:
>
> > Jason Kitchen wrote:
> > I still think you're missing the point - maybe I didn't explain myself clearly.
> > The solution you provide above means that each time you move a field from
> > "step 1 form" to "step 2 form" or vice-versa you need to modify the correct
> > "partialValidate" method. What I would like to do is to be able to move fields
> > to another form with no code impact (other than JSP). I think that this is what
> > the struts designers intended (comments from the struts developers ?) but
> > the validations are preventing the relaization of this goal.
> >
>
> Thanks Jason - that is exactly what I am trying to do.
> Maybe I am missing it but I have not heard a solution that does not
> involve a framework change??
>
> But Jason mentions this proposed modification
>
> > In addition I think that this is easily achievable with a few modifications to the
> > struts framework:
> >
> > - Change the ValidatingActionForm interface - the signature to the validate() method
> > becomes: public String[] validate(HttpServletRequest request);
> >
> > - In ActionServlet.processValidate() we need to pass the HttpServletRequest object
> > as a parameter when we call the validate method.
>
> I guess after having the HttpServletRequest you can go thru all of the
> arguments that were submitted and then select the ones to validate.
> This is kind of what struts is already doing for you
> by setting all of the variables in the bean.
> I guess I was hoping for something a little more cleaner. I
> Just not sure what?
>
> Am I misunderstanding the solution the modification will allow
>
I was working through how I could hack it to work. I'm not sure how far along
Craig is with his solution but I agree that something cleaner would be
appropriate along the same lines as the attribute setting in the current
implementation.
Craig - are you far enough along to be able to elaborate a little more what you
had in mind ?
-- Jason
Re: Multi-page form
Posted by Sean Moore <se...@mindspring.com>.
> Jason Kitchen wrote:
> I still think you're missing the point - maybe I didn't explain myself clearly.
> The solution you provide above means that each time you move a field from
> "step 1 form" to "step 2 form" or vice-versa you need to modify the correct
> "partialValidate" method. What I would like to do is to be able to move fields
> to another form with no code impact (other than JSP). I think that this is what
> the struts designers intended (comments from the struts developers ?) but
> the validations are preventing the relaization of this goal.
>
Thanks Jason - that is exactly what I am trying to do.
Maybe I am missing it but I have not heard a solution that does not
involve a framework change??
But Jason mentions this proposed modification
> In addition I think that this is easily achievable with a few modifications to the
> struts framework:
>
> - Change the ValidatingActionForm interface - the signature to the validate() method
> becomes: public String[] validate(HttpServletRequest request);
>
> - In ActionServlet.processValidate() we need to pass the HttpServletRequest object
> as a parameter when we call the validate method.
I guess after having the HttpServletRequest you can go thru all of the
arguments that were submitted and then select the ones to validate.
This is kind of what struts is already doing for you
by setting all of the variables in the bean.
I guess I was hoping for something a little more cleaner. I
Just not sure what?
Am I misunderstanding the solution the modification will allow
Thanks,
Sean
Re: Multi-page form
Posted by Jason Kitchen <ja...@s1.com>.
Jean-Baptiste Nizet wrote:
>
> Jason Kitchen wrote:
>
> > Sean Moore wrote:
> > >
> > > I also am very interested in the multipage "form".
> > >
> > > a quote from the old user manual reads:
> > > "Struts encourages you to define a single ActionForm bean that contains
> > > properties for all of the fields, no matter which page the field is
> > > actually displayed on. Likewise, the various pages of the same form
> > > should all be submitted to the same Action Class. If you follow these
> > > suggestions, the page designers can rearrange the fields among the
> > > various pages, with no changes required to the processing logic in
> > > most cases."
> > >
> > > What attracted me was the ability for designers to take my
> > > extra long one page form and turn it into as many pages as
> > > needed for normal people and not change any application logic.
> > >
> > > I have created a ActionForm called MultipageForm with all of the
> > > variables.
> > > I have created one Action called MultipageAction.
> > > I like only having one Action and only one ActionForm.
> > >
> > > My first sticking point is how do I validate the variables
> > > on just the submited page before moving to the next page?
> > > If my designers are moving things all around on
> > > different pages then how do I know which variable is on
> > > which page and when to validate it?
> > >
> > > Can someone point me in the right direction?
> > >
> > > When I get this working I would be glad to submit it as an
> > > example.
> > >
> > > Thanks,
> > > Sean
> >
> > This is something that we're trying to do now.
> > According to the struts user guide and looking at the source code
> > it appears that the developers want us to use a ValidatingActionForm.
> > Implementing the ValidatingActionForm means implementing the
> > validate method which has no parameters and hence no reference to the
> > HttpServletRequest is available to perform the validations. Since we
> > don't have access to the request how is it possible to figure out which
> > form attributes were passed to the servlet ?
> >
>
> Hi Jason. How is it going in Charlotte? ;-)
> The reason you don't need the HttpServletRequest for the validation is plain
> simple: thanks to Struts, the parameters passed by the browser will
> automatically be in the form itself (if a corresponding setter is found,
> obviously). So, if your form is to be used in a wizard (multiple pages), just
> add a "step" field in your form and sets it to 1 when the first screen of the
> wizard is submitted (thanks to a hidden field), to 2 when the second screen is
> submitted, and so on. In your validate, just dispatch to the right
> "partialValidate" method depending on the value of the step variable. Am I
> missing something?
>
> On the other hand, I would also like to have access to the HttpServletRequest in
> the validate method, in order to have access to other parameters in the request,
> or, more important, in the session. For example, the validate method could
> retrieve the locale of the current user in his session and validate dates,
> currencies, etc. in a locale-dependent way.
>
> Craig, is it something you plan to offer in a future release?
>
> >
> > May be some modifications are required to the API in order to support
> > this ?
> >
> > -- Jason
>
Things are going well in Charlotte thanks...
I still think you're missing the point - maybe I didn't explain myself clearly.
The solution you provide above means that each time you move a field from
"step 1 form" to "step 2 form" or vice-versa you need to modify the correct
"partialValidate" method. What I would like to do is to be able to move fields
to another form with no code impact (other than JSP). I think that this is what
the struts designers intended (comments from the struts developers ?) but
the validations are preventing the relaization of this goal.
In addition I think that this is easily achievable with a few modifications to the
struts framework:
- Change the ValidatingActionForm interface - the signature to the validate() method
becomes: public String[] validate(HttpServletRequest request);
- In ActionServlet.processValidate() we need to pass the HttpServletRequest object
as a parameter when we call the validate method.
-- Jason
Re: Multi-page form
Posted by Jean-Baptiste Nizet <je...@s1.com>.
Jason Kitchen wrote:
> Sean Moore wrote:
> >
> > I also am very interested in the multipage "form".
> >
> > a quote from the old user manual reads:
> > "Struts encourages you to define a single ActionForm bean that contains
> > properties for all of the fields, no matter which page the field is
> > actually displayed on. Likewise, the various pages of the same form
> > should all be submitted to the same Action Class. If you follow these
> > suggestions, the page designers can rearrange the fields among the
> > various pages, with no changes required to the processing logic in
> > most cases."
> >
> > What attracted me was the ability for designers to take my
> > extra long one page form and turn it into as many pages as
> > needed for normal people and not change any application logic.
> >
> > I have created a ActionForm called MultipageForm with all of the
> > variables.
> > I have created one Action called MultipageAction.
> > I like only having one Action and only one ActionForm.
> >
> > My first sticking point is how do I validate the variables
> > on just the submited page before moving to the next page?
> > If my designers are moving things all around on
> > different pages then how do I know which variable is on
> > which page and when to validate it?
> >
> > Can someone point me in the right direction?
> >
> > When I get this working I would be glad to submit it as an
> > example.
> >
> > Thanks,
> > Sean
>
> This is something that we're trying to do now.
> According to the struts user guide and looking at the source code
> it appears that the developers want us to use a ValidatingActionForm.
> Implementing the ValidatingActionForm means implementing the
> validate method which has no parameters and hence no reference to the
> HttpServletRequest is available to perform the validations. Since we
> don't have access to the request how is it possible to figure out which
> form attributes were passed to the servlet ?
>
Hi Jason. How is it going in Charlotte? ;-)
The reason you don't need the HttpServletRequest for the validation is plain
simple: thanks to Struts, the parameters passed by the browser will
automatically be in the form itself (if a corresponding setter is found,
obviously). So, if your form is to be used in a wizard (multiple pages), just
add a "step" field in your form and sets it to 1 when the first screen of the
wizard is submitted (thanks to a hidden field), to 2 when the second screen is
submitted, and so on. In your validate, just dispatch to the right
"partialValidate" method depending on the value of the step variable. Am I
missing something?
On the other hand, I would also like to have access to the HttpServletRequest in
the validate method, in order to have access to other parameters in the request,
or, more important, in the session. For example, the validate method could
retrieve the locale of the current user in his session and validate dates,
currencies, etc. in a locale-dependent way.
Craig, is it something you plan to offer in a future release?
>
> May be some modifications are required to the API in order to support
> this ?
>
> -- Jason
--
Jean-Baptiste Nizet
jean-baptiste.nizet@s1.com
R&D Engineer, S1 Belgium
Kleine Kloosterstraat, 23
B-1932 Sint-Stevens Woluwe
+32 2 200 45 42
Re: Multi-page form
Posted by Jason Kitchen <ja...@s1.com>.
Sean Moore wrote:
>
> I also am very interested in the multipage "form".
>
> a quote from the old user manual reads:
> "Struts encourages you to define a single ActionForm bean that contains
> properties for all of the fields, no matter which page the field is
> actually displayed on. Likewise, the various pages of the same form
> should all be submitted to the same Action Class. If you follow these
> suggestions, the page designers can rearrange the fields among the
> various pages, with no changes required to the processing logic in
> most cases."
>
> What attracted me was the ability for designers to take my
> extra long one page form and turn it into as many pages as
> needed for normal people and not change any application logic.
>
> I have created a ActionForm called MultipageForm with all of the
> variables.
> I have created one Action called MultipageAction.
> I like only having one Action and only one ActionForm.
>
> My first sticking point is how do I validate the variables
> on just the submited page before moving to the next page?
> If my designers are moving things all around on
> different pages then how do I know which variable is on
> which page and when to validate it?
>
> Can someone point me in the right direction?
>
> When I get this working I would be glad to submit it as an
> example.
>
> Thanks,
> Sean
This is something that we're trying to do now.
According to the struts user guide and looking at the source code
it appears that the developers want us to use a ValidatingActionForm.
Implementing the ValidatingActionForm means implementing the
validate method which has no parameters and hence no reference to the
HttpServletRequest is available to perform the validations. Since we
don't have access to the request how is it possible to figure out which
form attributes were passed to the servlet ?
May be some modifications are required to the API in order to support
this ?
-- Jason