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/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] ------------------------------------------------------- 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]
