Re: Content-type and transforms (was RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick)
- Original Message - From: Schnitzer, Jeff [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 7:04 PM Subject: RE: Content-type and transforms (was RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick) From: jim moore [mailto:[EMAIL PROTECTED] The nice about moving this functionality into the framework as opposed to the individual transforms is that it gives some regularity--it is very clear when looking at the maverick.xml file what the output of each transform is if necessary (no need to look at source code). Also, all existing transforms and views would work immediately without modification. It would be nice to be able to fix this so that everything works properly even if users don't specify a content-type for every step (something I doubt that most users will do consistently). The only downside is the API change, right? Yes I agree with this. All of the existing transform types in CVS right now extend AbstractTransformStep. All I have to do is add the dummy setContentType() method to AbstractTransformStep in the core and it will be unnecessary to modify any of the optional packages. Sound better? :-) Yes, I think this handles most of my concerns over breaking the api, though we might also need to do something to views as well. I think this discussion originally started over Mike's concern over setting the content-type when maxTransforms=0 (ie, a view, not a transform). I like this approach - it enables SAX-generating steps to specify content-type just like text-generating steps (which can specify the content-type on the HttpServletRequest). Agreed. I'm not going to harp on it too much more, but even with the above changes to the api (which I am now in favor of), I still sort of feel like the optional content-type attribute on views and transforms would be a nice option to offer. If present, it would basically override whatever the transform or view itself did. But I'm not going to press it too much more. If you feel like its overkill or confusing then I'll go along with your judgement. --jim --- 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]
Re: Content-type and transforms (was RE: [Mav-user] [PROPOSAL] Release v2.2.0 of Maverick)
I wasn't implying that the content-type be mandatory. Just that maverick
would use it if it were there. If not, Maverick would simply behave as it
does currently.
I think this should achieve our goals without any real api break. As the
attribute is not mandatory, existing apps would continue to work as they do
now, but if present, maverick would use it.
The nice about moving this functionality into the framework as opposed to
the individual transforms is that it gives some regularity--it is very clear
when looking at the maverick.xml file what the output of each transform is
if necessary (no need to look at source code). Also, all existing transforms
and views would work immediately without modification.
--jim
- Original Message -
From: Schnitzer, Jeff [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, March 24, 2003 5:46 PM
Subject: 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
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] [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]
[Mav-user] [PROPOSAL] Release v2.2.0 of Maverick
Yes, definitely worthwhile. My own projects use the latest-and-greatest third-party jars with no ill effect. I'll update the ones in CVS. With that change, is everyone comfortable with a 2.2 release? Jeff Schnitzer [EMAIL PROTECTED] -Original Message- From: Robert Leftwich [mailto:[EMAIL PROTECTED] Sent: Friday, March 21, 2003 4:07 PM To: [EMAIL PROTECTED] Subject: RE: [Mav-user] Accessing the Command string from the controller - Correction At 10:09 AM 22/03/2003, Schnitzer, Jeff wrote: BTW, I recommend using the CVS copy of Maverick right now - the getParams() method has been renamed to getControllerParams(). I wonder if it is worthwhile updating some (all?) of the libs in the CVS as they are quite old and the newer versions have had significant enhancement:? Has anyone been running Maverick with the latest and greatest jdom, bean-utils, collections and log4j? Any problems? Robert --- 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: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]
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
mav-2.1.2.patch
Description: Binary data
On Friday, March 21, 2003, at 05:30 PM, Schnitzer, Jeff wrote:
Yes, definitely worthwhile. My own projects use the
latest-and-greatest
third-party jars with no ill effect. I'll update the ones in CVS.
With that change, is everyone comfortable with a 2.2 release?
Jeff Schnitzer
[EMAIL PROTECTED]
-Original Message-
From: Robert Leftwich [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2003 4:07 PM
To: [EMAIL PROTECTED]
Subject: RE: [Mav-user] Accessing the Command string from the
controller -
Correction
At 10:09 AM 22/03/2003, Schnitzer, Jeff wrote:
BTW, I recommend using the CVS copy of Maverick right now - the
getParams() method has been renamed to getControllerParams().
I wonder if it is worthwhile updating some (all?) of the libs in the
CVS
as
they are quite old and the newer versions have had significant
enhancement:?
Has anyone been running Maverick with the latest and greatest jdom,
bean-utils, collections and log4j? Any problems?
Robert
---
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: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]
