[Framework-Team] Some preliminary Plone 3.0 profiling results

Alec Mitchell apm13 at columbia.edu
Tue Nov 14 15:37:19 UTC 2006

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).


More information about the Framework-Team mailing list