[Framework-Team] Some preliminary Plone 3.0 profiling results

[Alexander Limi]

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"?

We have done worse things in the past, and if it's clearly documented  
(maybe even has a dedicated knob in portal_migration to turn on/off),  
would that be a good way of doing this?

There's a lot of stuff we are in a difficult situation if we want to  
improve, since it will take a few versions to get rid of the old and very  
ineffective implementations.

I'm not suggesting we do this for everything, but for things like portlets  
and the contentmenu that both have a massively improved infrastructure  
(actually, they have infrastructure at all instead of just being templates  
with funny markup, but I digress… ;), and that we expect people to want to  
adopt very quickly.

Please note: This is very different from changing the method name /  
functionality of (for instance) toLocalizedTime in a release. API  
deprecation is a different beast, and should (and can!) be handled in a  
better way. Somewhat vague customization hooks that 5% of our audience  
uses is what I'm getting at here, see also Sidnei's comments about the  
edit form hooks. Shipping the to-be-removed hooks in a separate skin layer  
that can be turned on or off in the migration tool could be an approach  
worth looking at.

Just thinking out loud, I assume Joel will come and shoot me down on this  
really soon. Time to get some sleep. :)

-- 
_____________________________________________________________________

      Alexander Limi · Chief Architect · Plone Solutions · Norway

  Consulting · Training · Development · http://www.plonesolutions.com
_____________________________________________________________________

       Plone Co-Founder · http://plone.org · Connecting Content
   Plone Foundation · http://plone.org/foundation · Protecting Plone