Perhaps most of you already know this but it bit me this week. For my project I've noticed some sluggish presentation of pages, and a lot of container queries flying around for very simple pages. It turns out to be Javascript code (singleBranchTree.xml) that is walking one-level of parents, siblings and children for each of my pages, even though I don't have a nav tree widget in my skin.

I thought I was doing things the preferred way, by using the existing @@standard_macros/page and filling in slots to change out selected portions. It turns out that while there is a slot to disable the -display- of the nav tree, there isn't one for the page header to disable the -computation- of the nav tree, which is triggered from within the browser via navigation_tree.js upon the body load event.


It probably doesn't make a noticeable difference when your containers use the ZODB and only have a handful of items per folder. In my case most of my containers are SQL tables, with hundreds to thousands of records, so even a localized tree traversal results in SQL queries and instantiation of quite a few objects.

Besides rolling my own skin from scratch, my solution, since I can't slot it out, was to layer the navigation_tree_js with my own, modified copy:

  <browser:page
      for="*"
      name="skin_macros"
      permission="zope.View"
      layer="webaccountant"
      template="template_tablelayout.pt"
      />
<!--      layer="zope.app.rotterdam.rotterdam" -->

and then copy zope/app/rotterdam/template_tablelayout.pt into my project and edit it to comment out the line:

  <!--
     <metal:tree use-macro="context/@@standard_macros/navigation_tree_js" />
    -->

It made a world of difference in performance for me.  Your milage may vary.

-Jeff

_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to