Re: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
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 type=fop content-type=application/pdf/
/view
/controller
Maverick can be responsible for reading and applying these attributes and
then the existing transforms and views won't need to be modified at all. If
the attribute is missing, maverick can just behave as it does currently.
--jim
- Original Message -
From: Schnitzer, Jeff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, March 23, 2003 4:44 PM
Subject: RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Good point. In fact, it seems to me that the contract between transform
steps is currently insufficient - each step should probably make an
attempt to communicate to the subsequent step what the appropriate
content type is. That way no matter what type of transform you have,
halting should provide the appropriate content-type.
I'll try adding a setOutputType() method to the TransformStep
interface. Calling it will be recommended but optional. At the moment
I imagine that only the LastStep will do anything with it.
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: Mike Moulton [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 5:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Before releasing 2.2 there is a bug I noticed a while ago that doesn't
seem to have been fixed.
The problem is that the UNFINISHED_CONTENTTYPE isn't explicitly set
when maxTransforms=0. This caused problems on some browsers, primarily
IE 5.2 for Mac.
To fix this I add the following lines to the getNextStep() method in
MaverickContext.java.
if (this.transformCount == 0)
this.getRealResponse().setContentType(UNFINISHED_CONTENTTYPE);
These lines were added within the 'if' statement. The new 'if'
statement looks as follows.
if (this.nextTransform = this.transformCount)
{
if (this.transformCount == 0)
this.getRealResponse().setContentType(UNFINISHED_CONTENTTYPE);
this.log.debug(...which is the LastStep);
return new LastStep(this);
}
There is also a patch attached for the version contained in the 2.1.2
release.
Note: This may not be the best solution to the problem.
-- Mike
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
[INVALID FOOTER]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
[INVALID FOOTER]
Content-type and transforms (was RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick)
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 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 unhalted chain, in which case it is probably
text/html.
Right now DocumentViews and DocumentTransforms have a way of passing the
content-type - they call getResponse().setContentType(). For different
binding types (in particular, the SAX mechanism) there is not currently
any way of passing this information - so it seems that we should add it
to the TransformStep interface.
Yes, this changes the existing API a little, but I haven't thought of a
better way of making this work such that the default is right 90% of the
time. I'm certainly open to other ideas, of course.
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: jim moore [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 6:57 AM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
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 type=fop content-type=application/pdf/
/view
/controller
Maverick can be responsible for reading and applying these attributes
and
then the existing transforms and views won't need to be modified at
all.
If
the attribute is missing, maverick can just behave as it does
currently.
--jim
- Original Message -
From: Schnitzer, Jeff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, March 23, 2003 4:44 PM
Subject: RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Good point. In fact, it seems to me that the contract between
transform
steps is currently insufficient - each step should probably make an
attempt to communicate to the subsequent step what the appropriate
content type is. That way no matter what type of transform you have,
halting should provide the appropriate content-type.
I'll try adding a setOutputType() method to the TransformStep
interface. Calling it will be recommended but optional. At the
moment
I imagine that only the LastStep will do anything with it.
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: Mike Moulton [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 5:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Before releasing 2.2 there is a bug I noticed a while ago that
doesn't
seem to have been fixed.
The problem is that the UNFINISHED_CONTENTTYPE isn't explicitly set
when maxTransforms=0. This caused problems on some browsers,
primarily
IE 5.2 for Mac.
To fix this I add the following lines to the getNextStep() method in
MaverickContext.java.
if (this.transformCount == 0)
this.getRealResponse().setContentType(UNFINISHED_CONTENTTYPE);
These lines were added within the 'if' statement. The new 'if'
statement looks as follows.
if (this.nextTransform = this.transformCount)
{
if (this.transformCount == 0)
this.getRealResponse().setContentType(UNFINISHED_CONTENTTYPE);
this.log.debug(...which is the LastStep);
return new LastStep(this);
}
There is also a patch attached for the version contained in the
2.1.2
release.
Note: This may not be the best solution to the problem.
-- Mike
---
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
[INVALID FOOTER]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
[INVALID FOOTER]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
[INVALID FOOTER]
RE: [Mav-user] Directory heirarchy when using Shunts Modes
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/ Then the browser is going to try to load the file /include/foo.gif - it has no idea how things are really structured on the backend. Your Japanese vm file needs to have a full path: img src=jp/images/foo.gif/ Does that explain the problem you're having? Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Scott Chun [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 9:12 PM To: [EMAIL PROTECTED] Subject: [Mav-user] Directory heirarchy when using Shunts Modes I am using Velocity + Maverick and Dreamweaver to create the *.vm files. I first developed my *.vm files in English. To better organize my files, I create various subdirectories for images and includes. Then I added the org.infohazard.maverick.shunt.LanguageShuntFactory and created resources for mode=jp (Japanese). I placed the en jp files under: context-/en/*.vm ||--/images/*.gif | |--/brand_tabs/*.gif | |--/inactive_tabs/*.gif ||--/includes/*.css |---/jp-/*.vm |--/images/*.gif | |--/brand_tabs/*.gif | |--/inactive_tabs/*.gif |--/includes/*.css Everything works fine during design time, but as expected, not when I deployed. The *.vm files did not see the files in the images and includes subdirectories. Is there any way to make this directory structure work when I deploy? As usual, thanks. Scott -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. == --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en [INVALID FOOTER] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
Re: [Mav-user] ClassCastException
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 by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
[Mav-user] Re: Content-type and transforms (was RE: [PROPOSAL] Release v2.2.0 of Maverick)
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 unhalted chain, in which case it is probably text/html. The output of an XSLT can be almost anything text/html, application/xml+html, image/svg, application/foo+bar. Wont we need some way of setting this? -k. -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://www.rocketred.com.au/blogs/kevin/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf [INVALID FOOTER]
[Mav-user] A virtual url space?
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 that allows this? -k. -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://www.rocketred.com.au/blogs/kevin/ --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en [INVALID FOOTER]
RE: [Mav-user] A virtual url space?
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 [mailto:[EMAIL PROTECTED] Sent: Saturday, March 22, 2003 6:08 PM To: [EMAIL PROTECTED] Subject: [Mav-user] A virtual url space? 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 that allows this? -k. -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://www.rocketred.com.au/blogs/kevin/ --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en [INVALID FOOTER] --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en [INVALID FOOTER]
