On Tue, 14 Nov 2006 06:14:38 -0800, Martin Aspeli <[EMAIL PROTECTED]> 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

Framework-Team mailing list

Reply via email to