Well, I do have one idea, off the top of my head. It's a bit whacky, but in a perverse kind of way, it fits with what Stxx is all about. I'm not entirely sure it meets the Stxx folks' goals, though.
The idea is to allow for Struts to apply a transform to the config file before passing it to the Digester. In this particular case, a Stxx config file would be transformed by a Stxx-to-Struts XSL stylesheet, the result of which would be passed to the Digester as a regular struts-config.xml input stream. A separate Stxx Struts Plugin could then apply a different transform on the same Stxx config file, and perform the remaining Stxx-specific configuration for the web app. While this would mean maintaining a separate DTD for Stxx (assuming they want a validating parse), it does provide a great deal of flexibility in configuring Struts and extending it from a single config file. -- Martin Cooper -----Original Message----- From: Craig R. McClanahan To: Struts Developers List Sent: 7/23/2002 6:21 PM 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]>
