RE: Barracuda: About URLRewriting using DefaultDOMWriter

I wanted to keep this on the radar.

Christian, can you comment on the issues that zhihai is talking about 
here?  I also brought up some stuff in my reply (see below).  Maybe we can 
try to push some of the more XMLC specific stuff to the XMLC project and 
for the Barracuda stuff, make sure that it supports all the options of XMLC 
stuff.

Jake


At 04:30 PM 1/2/2003 -0500, you wrote:
>Hi, Jacob
>
>Thank you for your reply and recommendation.
>But  the problem here is we didn't use Barracuda Event Model part, we only 
>utilize Barracuda Components Models with XMLC for our view.
>
>And If  some of the dom.* and dom.io.* classes  are XMLC specific , may be 
>the community  can make it a utility package as the integration with XMLC. 
>Since Barracuda Component Model is one of the best tool to control the 
>XMLC DOM Rending.
>
>For example, If BaseDOMFormatter can recognize the XMLC DomumentInfo , 
>Even we only use  Barracuda Components Models , the BaseDOMFormatter  will 
>help us to do the URLRewritting . and DefaultDOMWriter can take different 
>OutputOptions and  help us to rendering the DOM tree.
>
>Thanks, zhihai
>
>
>  -----Original Message-----
>From: Jacob Kjome [mailto:[email protected]]
>Sent: Thursday, January 02, 2003 3:20 PM
>To: [email protected]
>Cc: Zhihai Li
>Subject: Re: Barracuda: About URLRewriting using DefaultDOMWriter
>
>
>Hi Zhihai,
>
>Barracuda takes a little different approach to URL rewriting that, 
>admittedly, might not utilize XMLC's existing OuputOptions very well.  The 
>way you turn it on is to put this in your event gateway configuration:
>
><constant class="org.enhydra.barracuda.plankton.http.URLRewriter" 
>name="REWRITE_URLS">true</constant>
>
>It supports URL rewriting not only through XMLC but also through the 
>components.  Actually, I really need to look back at this to see how it 
>all works again.  Your point is well taken; we shouldn't be interfering 
>with XMLC's native ability to do URL rewriting.  However, I think the idea 
>was to support other DOM implementations other than XMLC objects.  We 
>didn't want to tie Barracuda to it.  This will have to be looked into to 
>see how we can support it generically and not interfere with XMLC's native 
>abilities.  Any thoughts on this issue are welcome.
>
>Christian,
>
>I wonder if we should look into shaking out some of the dom.* and dom.io.* 
>classes to see how much these classes are actually needed.  I think the 
>original idea was to push some of this stuff over to XMLC since some of it 
>is XMLC specific and we only added further functionality to support some 
>of the things Barracuda needed to support.  This has already been done 
>with the xmlc taskdef.  It might be good to do some house cleaning.
>
>Jake
>
>
>At 06:41 PM 12/31/2002 -0500, Zhihai Li wrote:
>>Hi, Barracuda Community
>>I met a  Problem ----    on Barracuda ( 1.1.1 )  URLRewritting  and XMLC 2.1
>>
>>                    We are 
>> using  org.enhydra.barracuda.core.util.dom.DefaultDOMWriter.
>>                                 --  write(Node node, HttpServletResponse 
>> resp, OutputOptions oo)
>>                       and in the OutputOptions we add the 
>> implemented  URLRewriter .
>>
>>Result   ---   if we turned off the Brower cookie , the rendered page 
>>still don't have the Rewriting.
>>
>>Found  ----  and Looked at the source code,  actually it 
>>is  org.enhydra.barracuda.core.util.dom.io. BaseDOMFormatter
>>
>>                      try to do the real job , and the way it did is 
>> before using any Rewriter Passed , checking whether the Document or Node 
>> being rendered
>>
>>                      implemented  from Interface 
>> org.enhydra.barracuda.core.util.dom.io.DocumentInfo.
>>
>>Surprise ---   ( !!!!! This  DocumentInfo   is not implemented by any 
>>class in Barracuda or XMLC  --- XMLCObject   !!!!)
>>
>>                        and All the XMLCObject did implement   ---- 
>> org.enhydra.xml.io.DocumentInfo
>>
>>  Change ----  And we tested change the BaseDOMFormatter to use the 
>> DocumentInfo in XMLC  and URL Rewriting works perfectly  !!!
>>
>>So , I guess may be we have some reason to have two DocumentInfo , or may 
>>be a bug.
>>
>>Thanks, zhihai