RE: Barracuda: About URLRewriting using DefaultDOMWriter

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