[Framework-Team] Some preliminary Plone 3.0 profiling results
limi at plone.org
Tue Nov 14 14:33:54 UTC 2006
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
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
More information about the Framework-Team