You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <Cr...@eng.sun.com> on 2000/09/04 02:09:56 UTC
[PROPOSAL] New Struts Configuration File Format
Fellow Struts-en,
Over the past three months, I have been very pleased with the number of
people who have tried Struts, and found it to be useful. It is clear
that there is a place for a framework like this, so I'd like to move
forwards towards a formal 1.0 release -- ideally around mid-October
(which corresponds to ApacheCon Europe in London).
One of the areas that will be important to enhancing Struts
functionality in the future, without breaking backwards compatibility,
is to improve the format of the configuration file (action.xml) that is
used to tell the controller servlet how to operate. Therefore, I am
proposing to define a formal DTD for the configuration file, as attached
(struts-config.dtd), and have also included a modified version of the
example application configuration file that uses the new approach
(struts-config.xml). Migrating to this new configuration style has many
advantages, including:
* Employs a formal DTD, so that the configuration file can be
validated, generated correctly by development tools, and
edited by hand with an XML-knowledgeable editor.
* A standard way to set additional JavaBeans properties for
custom ActionForward and ActionMapping implementation
classes is available, using the <set-property> element. This
approach allows custom classes to be used without requiring
any changes to the DTD.
* Encapsulates existing information in the action.xml file in a
way that can be extended in the future, without breaking
backwards compatibility. There will be other things we want
to configure, and having <action-mappings> as the root element
is already constraining.
* Includes optional information about form beans that would allow
a development tool to be created that could automatically generate
the corresponding Java class files. I would anticipate that such a
tool would be added to the Struts library as soon as someone
wanted to write and contribute it.
This configuration file format is obviously not backwards compatible
with the existing "action.xml" layout, although converting from the old
format to the new one is straightforward. Therefore, if this
configuration file format gets accepted by the community, I propose that
we temporarily support *both* formats, but mark the "action.xml" format
as deprecated, and encourage people to migrate quickly to the new style.
What do you think? I'm interested in feedback both on whether this
sounds like a good idea or not, and on details of the DTD itself (this
is my first "significant" DTD, so I'm definitely open to suggestions
from those who are more familiar with XML than I am).
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: [PROPOSAL] New Struts Configuration File Format
Posted by Luis Arias <lu...@elysia.com>.
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Friday, September 08, 2000 6:53 PM
Subject: Re: [PROPOSAL] New Struts Configuration File Format
>
> That's certainly an interesting approach to the problem. I can see that
the
> "design time" stuff might be going overboard, but see below.
>
Sure, its a more complex approach, but it fits in with the way I see
projects being
built, at least here... There is an impedence problem between web design
and web
application...
> By the way, do current generation browsers do the right thing if you send
them
> XHTML right now?
>
Craig, I'm no expert on this but I tested this with a fairly
graphics oriented web site using tools like w3c's HtmlTidy and the results
are encouraging. I had no problems with the xhtml code in either IE5 or
NS4.7...
>
> There is one element of form beans that sort of overlaps "design time"
versus
> "run time", and that is when we start talking about specifying
validations. We
> need something at run time so that the action servlet knows what
validations to
> enforce automatically, and so that the custom tags can (optionally)
generate
> appropriate JavaScript code to do client side checks as well when that is
> feasible. And, at a minimum, we need to know the Java class name so we
can
> instantiate the correct bean.
>
> How do we provide this sort of information if we totally banish form beans
from
> the config file?
I think the answer to this depends on the way client-side or server-side
validation
will take place. I agree that what would be very cool would be a process
similar to
JSP page compilation on the fly. So in that case you would effectively need
a description
of this at run-time. If you think about this on a conceptual level, there
is another
of "navigational constraints" that it would be cool to specify, i.e., an
order on
the way pages are brought up (I must have gone to page A before going to B).
There are probably many others, for instance there may be a relationship
between
some form fields for which you would want to generate client-side code to
enforce.
Let's say some input field shoudl always be the total of two others,
something like that.
What would be really cool is to have the possibility to use different
languages to
specify these constraints by using a language attribute in the tag. For
instance, java
or javascript for server-side constraints, javascript for client-side, OCL
(object
constraint language) for server-side or client-side constraints that could
be
automatically generated in java or javascript, etc...
I recently saw on the argo/uml site that there is an OCL to java generator
written in java that
is open-source (I don't remember what license). This is an interesting
possibility
since it could mean the possibility of accepting input from UML modeling
tools as
far as these type of constraints are concerned.
I think we need to find a format that could withstand changes with respect
to these type
of evolutions, even if they are not likely to be integrated into the
framework any time soon
(well, who knows... ;-). Maybe simply separating these interface-type
constraints from the
description of the dynamics of the site (action.xml) would be warranted
(validation.xml ?).
But I'm not sure....
Luis.
Re: [PROPOSAL] New Struts Configuration File Format
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
See below.
Luis Arias wrote:
> ----- Original Message -----
> From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> To: <st...@jakarta.apache.org>
> Sent: Monday, September 04, 2000 7:48 PM
> Subject: Re: [PROPOSAL] New Struts Configuration File Format
>
> >
> > I agree, and I'm open to suggestion. The goal would be that I can write a
> tool
> > that auto-generates form bean classes, ideally without requiring the
> developer
> > to do any customization to the generated code. That way, if you (say)
> added a
> > new bean property, you would just regenerate the bean and not lose any of
> your
> > custom changes.
> >
> > I've seen alternative approaches to this problem that let you "reverse
> engineer"
> > custom code that was added to a generated class back out again, so that it
> can
> > get re-added to the new generated class. This seems quite a lot more
> > complicated and error prone, but it might be a better strategy.
> >
>
> Craig,
>
> I worked on another approach to the FormBean generation problem while I was
> on vacation... :)
>
> My basic need, and I believe this to be a fairly general requirement, is to
> integrate web designer's output (a navigationaly functional static html
> site) into the coding process resulting in a dynamic web app.
>
> My approach was to specify as much as possible in the web design stage using
> tools such as dreamweaver and to generate the form beans in the coding phase
> by parsing
> the html (or xhtml !). I showed it was possible to do this using XSLT.
>
That's certainly an interesting approach to the problem. I can see that the
"design time" stuff might be going overboard, but see below.
By the way, do current generation browsers do the right thing if you send them
XHTML right now?
>
> That's why I don't believe its a good idea to specify any type of form
> properties or constraints in the action.xml file. I see the action.xml as a
> run-time specification and not a design specification which could be used
> to generate code.
>
> However, maybe there could be another tool just for the purpose of
> generating code
> which would use a language (OCL ?) to specify the various constraints not
> already taken
> into account by the web design phase which along with the static site could
> then be used to generate form beans, validating form beans, etc...
>
There is one element of form beans that sort of overlaps "design time" versus
"run time", and that is when we start talking about specifying validations. We
need something at run time so that the action servlet knows what validations to
enforce automatically, and so that the custom tags can (optionally) generate
appropriate JavaScript code to do client side checks as well when that is
feasible. And, at a minimum, we need to know the Java class name so we can
instantiate the correct bean.
How do we provide this sort of information if we totally banish form beans from
the config file?
>
> Luis.
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: [PROPOSAL] New Struts Configuration File Format
Posted by Luis Arias <lu...@elysia.com>.
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Monday, September 04, 2000 7:48 PM
Subject: Re: [PROPOSAL] New Struts Configuration File Format
>
> I agree, and I'm open to suggestion. The goal would be that I can write a
tool
> that auto-generates form bean classes, ideally without requiring the
developer
> to do any customization to the generated code. That way, if you (say)
added a
> new bean property, you would just regenerate the bean and not lose any of
your
> custom changes.
>
> I've seen alternative approaches to this problem that let you "reverse
engineer"
> custom code that was added to a generated class back out again, so that it
can
> get re-added to the new generated class. This seems quite a lot more
> complicated and error prone, but it might be a better strategy.
>
Craig,
I worked on another approach to the FormBean generation problem while I was
on vacation... :)
My basic need, and I believe this to be a fairly general requirement, is to
integrate web designer's output (a navigationaly functional static html
site) into the coding process resulting in a dynamic web app.
My approach was to specify as much as possible in the web design stage using
tools such as dreamweaver and to generate the form beans in the coding phase
by parsing
the html (or xhtml !). I showed it was possible to do this using XSLT.
That's why I don't believe its a good idea to specify any type of form
properties or constraints in the action.xml file. I see the action.xml as a
run-time specification and not a design specification which could be used
to generate code.
However, maybe there could be another tool just for the purpose of
generating code
which would use a language (OCL ?) to specify the various constraints not
already taken
into account by the web design phase which along with the static site could
then be used to generate form beans, validating form beans, etc...
Luis.
Re: [PROPOSAL] New Struts Configuration File Format
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Richard Vowles wrote:
> The form bean idea looks like something I posted a while back on this list -
> but it is missing one feature that I thought fairly useful (which I have now
> implemented myself, I have decided to take the struts base and head off in a
> different direction) which is a validator class for form fields. This would
> make standard validation easier and more declarative. I had thought about
> providing some basic validators with the framework that could be specified
> (e.g. validator="zero-base-integer" or validator="date" or validator="time")
> but with the ability to specify an override class
> (validatorClass="blah.blah2.blah3.UsernameValidator")
>
See my separate message that agrees with this basic concept.
>
> Can't say I like the Java code in the XML a whole bundle tho... Seems a mite
> icky.
>
I agree, and I'm open to suggestion. The goal would be that I can write a tool
that auto-generates form bean classes, ideally without requiring the developer
to do any customization to the generated code. That way, if you (say) added a
new bean property, you would just regenerate the bean and not lose any of your
custom changes.
I've seen alternative approaches to this problem that let you "reverse engineer"
custom code that was added to a generated class back out again, so that it can
get re-added to the new generated class. This seems quite a lot more
complicated and error prone, but it might be a better strategy.
>
> Richard
Craig
Re: [PROPOSAL] New Struts Configuration File Format
Posted by Richard Vowles <rv...@sew.co.nz>.
The form bean idea looks like something I posted a while back on this list -
but it is missing one feature that I thought fairly useful (which I have now
implemented myself, I have decided to take the struts base and head off in a
different direction) which is a validator class for form fields. This would
make standard validation easier and more declarative. I had thought about
providing some basic validators with the framework that could be specified
(e.g. validator="zero-base-integer" or validator="date" or validator="time")
but with the ability to specify an override class
(validatorClass="blah.blah2.blah3.UsernameValidator")
Can't say I like the Java code in the XML a whole bundle tho... Seems a mite
icky.
Richard
----- Original Message -----
From: "Craig R. McClanahan" <Cr...@eng.sun.com>
To: <st...@jakarta.apache.org>
Sent: Monday, September 04, 2000 12:09 PM
Subject: [PROPOSAL] New Struts Configuration File Format
> * Includes optional information about form beans that would allow
> a development tool to be created that could automatically generate
> the corresponding Java class files. I would anticipate that such a
> tool would be added to the Struts library as soon as someone
> wanted to write and contribute it.