An alternative may be to define a "namespace" for the struts tags and
provide others an opportunity to mix tags in the files.
For example - it may be possible to have something like:
-----------------------
<struts:form-beans>
<struts:form-bean name="testbean"
type="org.apache.struts.webapp.exercise.TestBean"/>
</struts:form-beans>
<struts:AppTag>
<myapp:myTag myAttrib="myValue" />
</struts:AppTag>
------------------------------
or something similar.
The idea I'm attempting to demonstrate would be allowing the struts tags to still be
validated as they are namespace qualified.
The <struts:AppTag> idea is the creation of a special struts-config.xml tag that
allows application specific tags (qualified by their own namespaces)
to be embedded in a predictible place.
In reality it may be possible to accomplish mixing tags and retaining validation even
without the use of a special <struts:AppTag> tag.
It should be a requirement, though, that struts-config.xml files not contain the
namespace qualifiers to ensure backward compatibility.
"Craig R. McClanahan" <[EMAIL PROTECTED]> on 07/23/2002 09:21:59 PM
Please respond to "Struts Developers List" <[EMAIL PROTECTED]>
To: Struts Developers List <[EMAIL PROTECTED]>
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
Subject: RE: cvs commit:
jakarta-struts/src/share/org/apache/struts/action ActionServlet.java
On Tue, 23 Jul 2002, Martin Cooper wrote:
> Date: Tue, 23 Jul 2002 17:46:20 -0700
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: cvs commit:
> jakarta-struts/src/share/org/apache/struts/action ActionServlet.java
>
> Well that's kinda interesting. ;-)
>
> Since the use of custom additions to the config file will cause
validation
> against the DTD to fail, should we deliberately turn off validation if
this
> option is being used (i.e. ignore the value of the 'validating' init
param
> and always treat it as false)?
>
I'm having conversations with the Stxx guys about exactly this issue.
They really really really want to be able to run on top of a stock 1.1
release, and I'd like to see if we can accomodate that.
Right now, turning off validation has been disabled because we rely on
some of the default values (so that we can avoid references to
Action.XXXXX constants in the config classes, to help keep them
serializable .... yadda yadda). There are alternatives to this that I'm
looking into -- like copying all the manifest constants into an
org.apache.struts.Constants file and having Action.XXXXX refer to those
for backwards compatibility.
Even if we have to keep validation, there are some (unpleasant but usable)
options, like maintaining a separate DTD that was a superset of the
standard one. What I'd really like to find is a way that an existing DTD
can be extended (say, add the <transform> element nested inside a
<forward> that the Stxx guys want) without having to start from scratch.
Any ideas?
> --
> Martin Cooper
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
