[Framework-Team] Some preliminary Plone 3.0 profiling results

[Martin Aspeli]

Hi guys,

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

I'm a bit reluctant to do that because I don't want to maintain two
things at once.  Think plone_tableless.

It's surprisingly complex to think through how people may have used
macros, overriden variables etc to do various checks. At the very
least, this would probably require separate @@plone views (please, can
we rename that sucker?) since that's where a lot of the logic goes.

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

I'd rather write a "how to update your products" guide, if we can
manage to keep an issue tracker with tasks ("The BBB Sin Tracker")
that we know will need documenting. That's kind of just me being lazy
and selfish though, so I appreciate people may want or need us to be
more vigorous. Template BBB is just not very much fun.

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

The contentmenu customisations will have broken with every Plone
version before, and it's a somewhat silly thing to have expected
customisations to such a complex and convoluted template to survive
version upgrades. For this one, it'd actually be quite easy to have a
deprecated backwards compatible main_template (instead of pulling the
plone.contentmenu content provider in main_template, do it in
global_contentmenu and reference that from main_template - this makes
global_contentmenu essentially a dummy), but for the portlets, it'd be
harder.

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

:)

Martin