Re: DefaultDOMWriter

At 11:10 AM 8/6/2003 -0700, you wrote:
>Thanks Jake,
>My only problem with not using the write(node, response) method is that I 
>will not get to use all the goodies that the method does for me like 
>setting the cache and stuff. And moreover if the implementation changes 
>later on to provide more functionality I will miss out on that.
>I guess, as you say, I need to alter the usage of the DefaultWriter 
>depending on the content-type. Thanks, that clears it up for me for now.

What I provided for you was good workaround.  The write(Node, 
HttpServletResponse) method should still make a better attempt to set the 
correct content-type.  It should be changed to work better.  Any 
suggestions/patches are welcomed.

>On a different note, how would it be to provide stylesheet functionality 
>(may be as an add-on to barracuda-core)? So my event handlers generate XML 
>and then depending on some  configuration setting I transform the XML into 
>say PDF (using FO). Is it a good model to follow?

Do you mean that you would manipulate the DOM, produce XML, and then have a 
stylesheet to further manipulate that?  That shouldn't be too hard, 
actually.  In fact, you could write another DOMWriter that does exactly 
this.  The DefaultDOMWriter is just the default implementation provided for 
convenience.  There is nothing that says you can't create your own 
DOMWriter to do whatever you want.  I'm not sure it belongs in barracuda 
core, though.  If you write one and it proves useful, we'll definitely 
consider adding it to core.util.dom.

BTW, it seems to me that we should add the following to the DOMWriter 
interface...

public void write(Node node, OutputStream stream) throws IOException;

Thoughts?  Objections?  I don't think this would harm anyone since I highly 
doubt many out there have written a custom DOMWriter as of yet.

Jake

>Srini.
>
>Jacob Kjome wrote:
>
>>
>>Well, what do you know.  I was actually wondering why ServletResponse 
>>didn't provide a method to query what the current content type was set 
>>to.  Check this out for the new Servlet-2.4 spec....
>>http://tinyurl.com/j4xl
>>
>>
>>Servlet 2.4 spec says that ServletResponse now gets two more methods, 
>>(from sections 5.4, 14.2.22) Namely;
>>     String getContentType();
>>     void   setCharacterEncoding(String charset)
>>
>>
>>I wish they'd thought of that a long time ago.  We wouldn't even have 
>>this problem since we'd be able to check if a content type was set on the 
>>servlet response and not override it if it was already set....or at least 
>>do something based on what it is currently set to.
>>
>>Anyway, I tend to agree with Srini.  DefaultDOMWriter uses XMLC do 
>>perform output formatting and it has a setOutputOptions(OutputOptions) 
>>method.  We can query the OutputOptions for the appropriate content-type, 
>>or mime-type as it is referred to in OutputOptions.  All one has to do is 
>>do is....
>>
>>OutputOptions oo = DefaultDOMWriter.getDefaultOutputOptions(doc);
>>oo.setMIMEType("application/excel");
>>DOMWriter dw = new DefaultDOMWriter(oo);
>>dw.write(node, resp);
>>
>>The only caveat is that I don't think that getMIMEType() is guaranteed to 
>>be non-null since it is only there to override the mime type stored in 
>>the XMLC XMLObject.  So, we could check this value and use it if it is 
>>non-null, but then do some heuristics to figure out what the appropriate 
>>mime-type should be otherwise.
>>
>>Of course, the obvious way to avoid all this is to set the content type 
>>yourself on the response object, get the writer (or output stream) from 
>>the response object, and just call...
>>dw.write(node, writer);
>>
>>That way, the write(Node, HttpServletResponse) method can continue to do 
>>its thing, which should work in most cases, and you can either use its 
>>functionality or bypass it if it doesn't meet your requirements.
>>
>>Do any of those solutions clear things up for you?
>>
>>Jake
>>
>>
>>At 03:37 PM 8/4/2003 -0700, you wrote:
>>
>>>Thanks Christian and Jake.
>>>
>>>I do agree that setting content-type is not such a great idea but, we 
>>>have html content (a DOM object) that needs to be opened by the MS-excel 
>>>application. Its more like a shortcut to handling direct excel format. 
>>>So I set the content-type to "application/excel" even when the content 
>>>is not, so that the browser forwards it to excel app and then the excel 
>>>can simply open it as though it were a excel document. I hope that 
>>>clears it up. Do you know any better way other than to set the content-type?
>>>
>>>I think carrying the content type in the OutputOptions is another idea. 
>>>So I can set it and pass that object to the DOMWriter and the write 
>>>method could use it to set it in the response object.
>>>
>>>Thanks,
>>>Srini.
>>>
>>>Jacob Kjome wrote:
>>>
>>>>Hi Srini,
>>>>
>>>>At 02:22 PM 8/4/2003 -0700, you wrote:
>>>>
>>>>>In the write method of DefaultDOMWriter, the content-type is set 
>>>>>without regards to what was set before. In my application, I provide a 
>>>>>excel download using html content. So I need to set the content-type 
>>>>>to application/excel for some html documents that I spit out. Does 
>>>>>anybody have any suggestions?
>>>>>Sorry if this question has already been asked. Please point me in the 
>>>>>right direction.
>>>>
>>>>
>>>>
>>>>It is a good question.  I have a question for you.  Why would you use a 
>>>>content type of "application/excel" for "html content".  if it is 
>>>>"html", then it isn't an excel document.  Well, I'm probably missing 
>>>>some details.  That said, I think you are right.
>>>>Overriding the content type in DefaultDOMWriter is probably not a good 
>>>>idea.  I wonder if that code shouldn't be removed entirely?
>>>>Would this cause any problems for anyone?  I can imagine i might, but 
>>>>I'd like to hear opinions from others.
>>>>
>>>>Jake
>>>>_______________________________________________
>>>>Barracuda mailing list
>>>>[email protected]
>>>>http://barracudamvc.org/lists/listinfo/barracuda
>>>
>>>
>>>
>>>_______________________________________________
>>>Barracuda mailing list
>>>[email protected]
>>>http://barracudamvc.org/lists/listinfo/barracuda
>>
>>
>>_______________________________________________
>>Barracuda mailing list
>>[email protected]
>>http://barracudamvc.org/lists/listinfo/barracuda
>
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda