I think this is a fairly elegant solution to the content-type attribute problem. Basically it follows the same decorator pattern used for TransformWithParams:
The CreateTransform method of MasterFactory could be modified as so:
/**
* Creates a possibly decorated transform.
*/
protected Transform createTransform(Element transformNode)
throws ConfigException
{
Transform t = this.createPlainTransform(transformNode);
Map params = XML.getParams(transformNode);
if (params != null)
t = new TransformWithParams(t, params);
//if there is a content-type attribute on the transform node, use it
if (transformNode.getAttribute("content-type")!=null)
t = new TransformWithContentType(t,
transformNode.getAttribute("content-type").getValue());
return t;
}
The new class TransformWithContentType is attached.
Something similar could easily be done for view as well if this is
acceptable.
--jim
----- Original Message -----
From: "Schnitzer, Jeff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 26, 2003 6:58 PM
Subject: RE: Content-type and transforms (was RE: [Mav-user] [PROPOSAL]
Release v2.2.0 of Maverick)
> From: jim moore [mailto:[EMAIL PROTECTED]
>
> 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).
All I need to do call setContentType("text/xml") from the DomifyView.
The current behavior of all other view types should be fine.
> 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.
It does seem like a good idea, but I'm not sure it would be used outside
of XSLT (which already allows specifying the output-type). For document
transforms, the content-type is usually set within the template using
the request.setContentType() method.
If I knew an easy solution, I would probably implement it immediately,
but I suspect a framework-level process for interpreting content-type on
view and transform configuration nodes might be more complicated than it
would be worth. It might be easier to implement content-type
interpretation on a view-by-view, transform-by-transform basis and
simply provide some tools in the core to make it easier. Dunno. Of
course, if you have an elegant solution, you're welcome to make the
changes ;-)
There is enough ambiguity here that my inclination is to follow the
YAGNI principle - we've addressed Mike's specific concern, and if
someone else comes up with a compelling use case then we can revisit the
issue.
Jeff Schnitzer
[EMAIL PROTECTED]
-------------------------------------------------------
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]
TransformWithContentType.java
Description: Binary data
