Re: DefaultDOMWriter

I thought of one other solution that I should have brought up before.  You 
can simply use a servlet filter to do whatever you want with the resulting 
servlet response.  You can change the content-type, do XSL Transformation, 
etc...  This is the probably the nicest solution because you really don't 
have to worry about how the DOMWriter works.  You know it outputs a HTML or 
XML and that's all you have to know.  Your code doesn't change.  You can do 
it all from afar.

Jake

At 01:56 PM 8/6/2003 -0500, you wrote:
>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
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda