[Framework-Team] Some preliminary Plone 3.0 profiling results

Martin Aspeli optilude at gmx.net
Tue Nov 14 15:47:39 UTC 2006

On 11/14/06, Alec Mitchell <apm13 at columbia.edu> wrote:
> On 11/14/06, Alexander Limi <limi at plone.org> wrote:
> > On Tue, 14 Nov 2006 06:14:38 -0800, Martin Aspeli
> > <optilude at gmx.net> wrote:
> >
> > > This is some portlets BBB stuff for people with main_template
> > > customisations that make globalize do slightly silly things. We could
> > > probably cut that out if we don't mind breaking some customisations.
> >
> > This seems to be a recurring theme. How about we ship Plone with a skin
> > layer plone_unoptimized that enables all these old uses of Plone overrides
> > that work in 1.x/2.x, but not let it be enabled by default, and put a big
> > "If you are experiencing problems with older products, you can enable the
> > plone_unoptimized layer as a transition strategy until your products and
> > customizations have been updated"?
> For this case such a thing is complete overkill, all we need to do is
> rewrite the existing default portlets so that they don't depend on
> global_defines stuff, and fully utilize the new portlet machinery (so
> classic.pt is never used).   This is not a large task.  Legacy
> portlets will still work via classic.pt, but they will slow down the
> site.  Maybe we can have an optimized_classic renderer for classic
> style portlets that don't depend on global_defines crap even.
> The portlets hardly depend on the global defines stuff at all, and
> when they do it's only the least expensive bits of it.  Calling it for
> every portlet is absurd, allowing old products to continue running by
> calling it is acceptable (a deprecation warning should be issued for
> all non-optimized classic portlets).


However, there's other portlets BBB related to the way
_prepare_slots() (called from globalize()) defines variables which are
then checked by tal:condition statements in main_template. If you have
a customised main_template, you're probably using these (variables
'sl' and 'sr') at *least* to determine whether left slots and right
slots should be shown.

Fixing your template to use the new portlets stuff is easy (you
probably only need a content provider; we may also want some more sane
names for the "showLeftPortlets" and "showRightPortlets" variables).
The current code attempts to do BBB, but has no real tests to prove
that it actually works. :)


More information about the Framework-Team mailing list