RE: Rendering Bug?

Hi Kirk,

Here's my commit notes on changes to DefaultDOMWriter...

<quote>
Modified DefaultDOMWriter and in the process, removed printPretty,
preventCaching, and maxAge from DefaultViewHandler and ComponentGateway.
Dealing with these values is now entirely localized to 
DefaultDOMWriter.  If you
want to override defaults, then override getDOMWriter() or just create a
DefaultDOMWriter and set the properties. before calling the write() method.
</quote>

So, you can do the following....
Note that maxAge defaults to 0 and only takes effect if preventCaching is 
false.  The relevant code is...

         //if we need to prevent caching
         if (preventCaching) {
             //add the appropriate headers to the response
             if (logger.isDebugEnabled()) logger.debug("updating resp hdr 
to prevent caching");
             resp.setHeader("Pragma","no-cache");
             resp.setHeader("Cache-Control","no-cache");
             resp.setDateHeader("Expires", System.currentTimeMillis());

         //csc_061202.1 - added
         //otherwise explicitly give it a max-age (this will generally 
allow browsers like
         //IE to page back in history without reloading, but if the user 
actually revisits the
         //URL, then it will still be reloaded)
         } else {
             resp.setHeader("Cache-Control","max-age="+maxAge);
             resp.setDateHeader("Last-Modified", System.currentTimeMillis());
         }


So....

new DefaultDOMWriter(DefaultDOMWriter.getDefaultOutputOptions(page), 
app.getDomPrettyPrinting(), app.getPreventCaching(), 0).write(page, resp);

or

//OutputOptions may be null.  Default OutputOptions are obtained internally 
if you pass in null.  I suppose that
//should be stated in the javadoc.
new DefaultDOMWriter(null, app.getDomPrettyPrinting(), 
app.getPreventCaching(), 0).write(page, resp);

or

DefaultDOMWriter ddw = new DefaultDOMWriter(app.getDomPrettyPrinting());
ddw.setPreventCaching(app.getPreventCaching());
ddw.write(page,resp);

or

DefaultDOMWriter ddw = new DefaultDOMWriter();
ddw.setPrettyPrint(app.getDomPrettyPrinting());
ddw.setPreventCaching(app.getPreventCaching());
ddw.write(page,resp);


One of those should work for you.

Jake


At 08:39 PM 6/22/2003 +0200, you wrote:
>Hi Jake,
>
>Slowly making the move to 2.0.
>
>What should I replace the following with?
>The method signiture has changed??
>
>new 
>DefaultDOMWriter(app.getDomPrettyPrinting(),app.getPreventCaching()).write(page,resp);
>
>Regards
>KD
>-----Original Message-----
>From: Jacob Kjome [mailto:[email protected]]
>Sent: 20 June 2003 07:10
>To: [email protected]
>Subject: RE: [Barracuda] Rendering Bug?
>
>Hi Kirk,
>
>Note that you will need to have xercesImpl.jar (Xerces2) + xml-apis.jar or 
>xmlParserAPIs.jar in your classpath.  Actually, put them in one of the 
>common lib directories in Tomcat 3.3.  Remove any older xmlc-* 
>jars....especially the xerces 1.4.4 jar.
>
>One quick way to see which jars you need in your WEB-INF/lib is to run 
>"ant install" on the Barracuda build and then look at the resulting jars 
>in WEB-INF/lib.  You can copy the jars from there.  The ones you need are 
>(in alphabetical order)...
>
>barracuda-core.jar
>bcel-5.1.jar
>gnu-regexp-1.1.4.jar
>jtidy-r7-xmlc-2.2.jar
>log4j-1.2.8.jar
>log4j-sandbox-selector-0.1alpha.jar
>log4j-sandbox-servlet-0.1alpha.jar
>plankton.jar
>xmlc-all-runtime-2.2.jar
>
>
>To use the Localize taskdef, you will also need the following jar in your 
>Ant build classpath...
>
>WEB-INF/jars/xmlc-taskdef-2.2.jar and, obviously, barracuda-ant.jar
>
>Also, read this:
>http://www.barracudamvc.org/Barracuda/docs/build_deploy.html
>
>Make sure also to check Barracuda's web.xml and event-gateway.xml to see 
>if there are any changes you might need to take into account.  One thing 
>might be the log4j initialization stuff (if you use it) which moved from 
>Barracuda's codebase to the log4j sandbox codebase.  Of course, you'll 
>need to use the InitServlet rather than the InitContextListener for Tomcat 
>3.3.  You should really think about updating to the latest Tomcat 4.1.xx 
>where you can take advantage of servlet 2.3.
>
>If you have any specific issues with all this, let me know.
>
>Jake
>
>
>At 06:54 PM 6/20/2003 +0200, you wrote:
>>Urrrm.... yep...
>>
>>Haven't upgraded yet.
>>
>>I tried about a week ago.
>>Had problems getting the new xmlc release working with Barracuda.
>>Or more to the point..
>>
>>Getting it working under Tomcat 3.3... :(
>>
>>Will try again tom morning/afternoon...
>>
>>This is def on my todo list.
>>-----Original Message-----
>>From: Jacob Kjome [mailto:[email protected]]
>>Sent: 20 June 2003 06:44
>>To: [email protected]
>>Subject: RE: [Barracuda] Rendering Bug?
>>
>>Hi Kirk,
>>What version of Barracuda did you say you were using?  Have you tried 
>>1.2.0 or even the latest CVS?  I think you will find a lot of bugs have 
>>been fixed and some things have been improved.  I would try the upgrade 
>>and see if it fixes any of your issues.  If it does, well, there you 
>>go.  Don't need to worry about those things anymore.
>>Jake
>>At 05:32 PM 6/20/2003 +0200, you wrote:
>>>Hi Christian,
>>>Will consider using the custom model approach...
>>>Will report if this works or not.
>>>Thanx
>>>Regards
>>>KD
>>>-----Original Message-----
>>>From: Christian Cryder [mailto:[email protected]]
>>>Sent: 20 June 2003 05:01
>>>To: [email protected]
>>>Subject: RE: [Barracuda] Rendering Bug?
>>>Hmmm...this is quite odd. I wonder if that particular element is actually
>>>getting rendered twice? Might be interesting to stick a debug line in place
>>>and then see if the model is getting called multiple times for the same
>>>element.
>>>Another thing to consider is whether XMLC is somehow mucking with the
>>>structure (that's something of a longshot, since <div>s can be nested).
>>>One other thing to consider...while the approach you've outlined (returning
>>>null to control visibility) _should_ work, I personally prefer a different
>>>approach where you use a custom directive to control visibility. For
>>>instance,
>>><div id="portlet_CallDesk"
>>>class="Dir::IsVisible.GetPage.p_has_access_calldesk_portal_calldesk">
>>>What this requires you to do is implement the process_Directive method in
>>>your model:
>>>     //process any custom directives
>>>     public boolean processDirective(TemplateDirective td) {
>>>         if (td.getCommand().equals(IS_VISIBLE)) {
>>>             ...return true or false...
>>>         } else {
>>>             return true;
>>>         }
>>>     }
>>>THe advantage of this approach is that if you return false, no nodes below
>>>this are processed (whereas in the approach where you return null or an
>>>invisible component from getItem(), child nodes ARE still processed. So
>>>there are obvious performance advantages in taking this approach.
>>>Let us know if that helps...
>>>Christian
>>>----------------------------------------------
>>>Christian Cryder
>>>Internet Architect, ATMReports.com
>>>Project Chair, BarracudaMVC - http://barracudamvc.org
>>>----------------------------------------------
>>>"Coffee? I could quit anytime, just not today"
>>>
>>> > -----Original Message-----
>>> > From: [email protected]
>>> > [mailto:[email protected]]On Behalf Of Kirk Daries
>>> > Sent: Friday, June 20, 2003 8:31 AM
>>> > To: [email protected]
>>> > Subject: [Barracuda] Rendering Bug?
>>> >
>>> >
>>> > Hi Guys,
>>> >
>>> > I've come across a strange bug when one of my pages is rendered?
>>> >
>>> > Note the 'Dir::Get_Data.GetPage.p_has_access_calldesk_portal_calldesk'
>>> > directive.
>>> > This returns a BComponent if a user has rights to view the 'Div'.
>>> > It returns null when validation fails.
>>> >
>>> > Now..onto the bug.
>>> >
>>> > If validation is successful... processing continues until the next
>>> > directive.
>>> > Namely, 'Dir::Get_Data.GetPage.p_has_access_calldesk_anonymous_call_log'
>>> > This also evaluates based on the users security rights.
>>> > However, if I return null, to prevent the node from rendering, Barracuda
>>> > still
>>> > renders the node?
>>> >
>>> > Anyone got any clue as to why this is happening?
>>> >
>>> > Regards
>>> > KD
>>> >
>>> >   <div id="portlet_CallDesk" class="portletTable
>>> > Dir::Get_Data.GetPage.p_has_access_calldesk_portal_calldesk">
>>> >     <div align="center" class="td_4">CallDesk</div>
>>> >       <div
>>> > class="Dir::Get_Data.GetPage.p_has_access_calldesk_anonymous_call_log">
>>> >         <span class="td_2"><a  class="hlink"
>>> > href="/barraframework/GetRequestPage.event?p_application=CallDesk">Log a
>>> > Call</a></span>
>>> >       </div>
>>> >
>>> >       <div
>>> > 
>>> class="Dir::Get_Data.GetPage.p_has_access_calldesk_my_calls_calculations"
>>> > style="width: 75%;float:left;">
>>> >             <span class="td_2
>>> > Dir::Get_Data.CallDeskEntry.p_mycalls_link">My
>>> > Calls</span>
>>> >       </div>
>>> >       <div class="Transparent
>>> > Dir::Get_Data.GetPage.p_has_access_calldesk_my_calls_calculations">
>>> >           <span
>>> > class="Dir::Get_Data.CallDeskEntry.p_mycalls_count">###</span>
>>> >       </div>
>>> >   </div>
>>> > _______________________________________________
>>> > 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