I am also in favor of using namespaces. Struts tags can use the
default namespace (no prefix), and custom tags use their own namespace.
Checking the Digester documentation, it appears it support namespaces,
and you can associate a RuleSet to a namespace.
Normally, namespaces should also work with DTD, ensuring proper
validation (or did I miss something ?)
In fact, I think of using namespaces in struts-config to allow
"inline" declaration of a Tiles definitions inside a <forward>.
Regarding some previous mails I think it is a similar requirement than
for the <transform> tag. So, we should certainly propose a common and
general solution for this kind of extension.
I will try to play a little bit more with namespaces, digester and
user configurable files ;-).
Cedric
[EMAIL PROTECTED] wrote:
>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]>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
