You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Simon Oldeboershuis <so...@outermedia.de> on 2000/09/01 21:52:49 UTC
Struts and the form lib
Hi,
we are planning to use struts for our webapplication and we like the
idea of using the formtag lib, BUT our forms are partly dynamic.Dynamic
forms in this context means a varying number of input fields,
checkboxes, database based options ... If I understood the usage of the
formtag lib right, there is no support for dynamic forms.
My question is, is it possible to support dynamic forms with the
strutstaglib? If not is there any plan to do it or can we contribute by
developing it?
thanks!
simon
Re: Struts and the form lib
Posted by Luis Arias <lu...@elysia.com>.
Hello !
>
> This isn't going to help you construct the forms themselves, though ...
the
> Struts form tags assume that the previous bean values will be actual
properties
> of a real bean, rather than looked up generically. What kind of
modifications to
> the form beans do you think might make sense to support this?
>
Maybe there should be some kind of support for "dynamic" forms in the
following sense:
* in the form tags - if no accessor is found, try a standard method (not
necessarily defined), e.g.,
public String getAttribute(String name);
* in populating the bean - if no accessor is found, use a standard method
(not necessarily defined), e.g.,
public void setAttribute(String name, String value);
These generic accessors would use a Hashtable or Map underneath in some
FormBean abstract base class (DynamicFormBean ?).
Luis.
Re: Struts and the form lib
Posted by James Strachan <ja...@metastuff.com>.
I think the restriction that a Form must be a JavaBean with getters &
setters for all of the form 'fields' could be lifted for dynamic forms. I'd
like it to be possible to use a Map instance to store the key/value pairs of
the form data and have form validators which use a Map.
We could have a small interface something like :-
public interface MapFormValidator {
public String[] validate( Map formData );
}
Both the 'type safe' and 'dynamic' approaches have their pros and cons.
Regards
James
James Strachan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
web: http://www.metastuff.com
mail: james@metastuff.com
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: 04 September 2000 20:15
Subject: Re: Struts and the form lib
> Simon Oldeboershuis wrote:
>
> > Hi,
> >
> > I think there was a misunderstanding, I was not precise enough by
> > describing the aim of our webapplication. This is the problem...
> >
> > the forms that we want to implement are so dynamic that is not possible
> > to ensure that the form bean has all the properties that we ever submit.
> > Even worst, not only the number of fields will be different in these
> > forms; the types of the fields (radio buttons, text fields) will be also
> > different every time, and there are THOUSANDS of generated dynamic
> > forms.
> >
> > It doesn't seem very nice to generate dynamically a bean for every
> > form. There has to be something like a setter with name, value
> > parameter... which is not really bean conform (is it?). However, I am
> > not sure if this a direction struts want to aim at ... So that we were
> > thinking about to develop a new tag library designed to manage this kind
> > of forms. Suggestions on how to implement it are welcomed.
> >
> > Simon
> >
> > PS: I think it can ease a lot of pain, having a generic interface to all
> > parameters via name value.
> >
>
> There is such a generic interface already available for receiving and
processing
> the dynamic parameters of an incoming request -- your action method could
do
> something like this (assuming it is a GET -- similar but different code is
needed
> for a POST):
>
> String queryString = request.getQueryString();
> Hashtable parameters =
> HttpUtils.parseQueryString(queryString);
>
> and you will get back a Hashtable that is keyed by parameter name. The
values
> will be String arrays of all the values that were submitted for that
particular
> parameter, and you can go grab what you need.
>
> This isn't going to help you construct the forms themselves, though ...
the
> Struts form tags assume that the previous bean values will be actual
properties
> of a real bean, rather than looked up generically. What kind of
modifications to
> the form beans do you think might make sense to support this?
>
> 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: Struts and the form lib
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Simon Oldeboershuis wrote:
> Hi,
>
> I think there was a misunderstanding, I was not precise enough by
> describing the aim of our webapplication. This is the problem...
>
> the forms that we want to implement are so dynamic that is not possible
> to ensure that the form bean has all the properties that we ever submit.
> Even worst, not only the number of fields will be different in these
> forms; the types of the fields (radio buttons, text fields) will be also
> different every time, and there are THOUSANDS of generated dynamic
> forms.
>
> It doesn't seem very nice to generate dynamically a bean for every
> form. There has to be something like a setter with name, value
> parameter... which is not really bean conform (is it?). However, I am
> not sure if this a direction struts want to aim at ... So that we were
> thinking about to develop a new tag library designed to manage this kind
> of forms. Suggestions on how to implement it are welcomed.
>
> Simon
>
> PS: I think it can ease a lot of pain, having a generic interface to all
> parameters via name value.
>
There is such a generic interface already available for receiving and processing
the dynamic parameters of an incoming request -- your action method could do
something like this (assuming it is a GET -- similar but different code is needed
for a POST):
String queryString = request.getQueryString();
Hashtable parameters =
HttpUtils.parseQueryString(queryString);
and you will get back a Hashtable that is keyed by parameter name. The values
will be String arrays of all the values that were submitted for that particular
parameter, and you can go grab what you need.
This isn't going to help you construct the forms themselves, though ... the
Struts form tags assume that the previous bean values will be actual properties
of a real bean, rather than looked up generically. What kind of modifications to
the form beans do you think might make sense to support this?
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: Struts and the form lib
Posted by Simon Oldeboershuis <so...@outermedia.de>.
Hi,
I think there was a misunderstanding, I was not precise enough by
describing the aim of our webapplication. This is the problem...
the forms that we want to implement are so dynamic that is not possible
to ensure that the form bean has all the properties that we ever submit.
Even worst, not only the number of fields will be different in these
forms; the types of the fields (radio buttons, text fields) will be also
different every time, and there are THOUSANDS of generated dynamic
forms.
It doesn't seem very nice to generate dynamically a bean for every
form. There has to be something like a setter with name, value
parameter... which is not really bean conform (is it?). However, I am
not sure if this a direction struts want to aim at ... So that we were
thinking about to develop a new tag library designed to manage this kind
of forms. Suggestions on how to implement it are welcomed.
Simon
PS: I think it can ease a lot of pain, having a generic interface to all
parameters via name value.
"Craig R. McClanahan" wrote:
>
> Simon Oldeboershuis wrote:
>
> > Hi,
> >
> > we are planning to use struts for our webapplication and we like the
> > idea of using the formtag lib, BUT our forms are partly dynamic.Dynamic
> > forms in this context means a varying number of input fields,
> > checkboxes, database based options ... If I understood the usage of the
> > formtag lib right, there is no support for dynamic forms.
> >
> > My question is, is it possible to support dynamic forms with the
> > strutstaglib? If not is there any plan to do it or can we contribute by
> > developing it?
> >
>
> I do not see any difficulty in handling "dynamic" forms in the sense that
> you are speaking here. The only fixed aspect of the current Struts form
> approach is that the Java class of the form bean is tied to the request URI
> (such as "/saveRegistration.do") that you submit the form to. On each and
> every submit, Struts matches up the request parameters that were entered on
> that particular request against the properties of the form bean, and calls
> the appropriate property setter methods. If the bean has additional
> properties for which no request parameters were included on this particular
> submit, they are left unchanged. Thus, you would need to ensure that your
> form bean has all the properties you would ever submit from this particular
> form, and you should be OK.
>
> For dynamic lists of select options, one common approach would be to create
> two parallel collections of the values (to be returned to the server) and
> labels (to be shown in the combo box to the user), and then use the
> <struts:options> tag to include them inside a <struts:select> element.
>
> If you have additional suggestions on how to make Struts even more amenable
> to dynamic forms, I'd be happy to entertain a discussion (on the STRUTS-DEV
> mailing list) of what such added support might look like, and code
> contributions to make it real.
>
> >
> > thanks!
> > simon
>
> Craig McClanahan
>
> ====================
> 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: Struts and the form lib
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Simon Oldeboershuis wrote:
> Hi,
>
> we are planning to use struts for our webapplication and we like the
> idea of using the formtag lib, BUT our forms are partly dynamic.Dynamic
> forms in this context means a varying number of input fields,
> checkboxes, database based options ... If I understood the usage of the
> formtag lib right, there is no support for dynamic forms.
>
> My question is, is it possible to support dynamic forms with the
> strutstaglib? If not is there any plan to do it or can we contribute by
> developing it?
>
I do not see any difficulty in handling "dynamic" forms in the sense that
you are speaking here. The only fixed aspect of the current Struts form
approach is that the Java class of the form bean is tied to the request URI
(such as "/saveRegistration.do") that you submit the form to. On each and
every submit, Struts matches up the request parameters that were entered on
that particular request against the properties of the form bean, and calls
the appropriate property setter methods. If the bean has additional
properties for which no request parameters were included on this particular
submit, they are left unchanged. Thus, you would need to ensure that your
form bean has all the properties you would ever submit from this particular
form, and you should be OK.
For dynamic lists of select options, one common approach would be to create
two parallel collections of the values (to be returned to the server) and
labels (to be shown in the combo box to the user), and then use the
<struts:options> tag to include them inside a <struts:select> element.
If you have additional suggestions on how to make Struts even more amenable
to dynamic forms, I'd be happy to entertain a discussion (on the STRUTS-DEV
mailing list) of what such added support might look like, and code
contributions to make it real.
>
> thanks!
> simon
Craig McClanahan
====================
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