Re: DefaultDOMWriter

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.

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?

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
>