Just as an alternate, maybe it might make sense to use an attributes in
maverick.xml on views and transforms to support this. Something like
controller class=com.foo.FooController
view name=success content-type=text/xml
transform type=xslt content-type=text/xml/
transform
I would hate to require content-type to be explicitly set on each step.
And without some input from the view or transform code, it's impossible
for the Maverick core to choose a sensible default.
For example, the output of a DomifyView should always be text/xml, but
the output of a DocumentView
Can you show an example of your vm files? I'm taking a wild guess at
what you're trying to do here.
Server-side includes will work with relative paths, however client-side
includes won't. If you have a command something.m which includes a
snippet of HTML like this:
img src=images/foo.gif/
I'm also having the exact same problem, even with a simple template like
this Resin just crashes brutally:
xsl:template match=/
xsl:copy-of select=* /
/xsl:template
___
SIMEN BREKKEN / in his prime.
---
This sf.net email is sponsored
On Mon, 24 Mar 2003 14:46:49 -0800, Schnitzer, Jeff wrote:
For example, the output of a DomifyView should always be text/xml, but the
output of a DocumentView is probably going to be text/html or text/plain.
The output of an XSLTransform is usually text/xml, unless it is the last
node in an
The thing I love most about cocoon is the ability to have a virtual url
space that allows for urls like /app/users/kevin/edit.html rather than he
more traditional /app/users/edit.xxx?user=kevin.
Is maverick able to do the former. If not is anyone else interested in
adding a dispatcher subclass
Wouldn't this best be done as a Servlet Filter? It seems like it would
be pretty easy to parse up the request string, morph it into a
traditional request, and pass it on... no need to modify Maverick's
Dispatcher.
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: Kevin O'Neill
