[Framework-Team] Re: Review of PLIP 142 - Martin vs. global_contentmenu

[Martin Aspeli]

Hi Hanno,

> The short summary is:
> 
> Martin vs. global_contentmenu round 1: Martin uses his special attack
> called "viewlets and contentproviders" and wins the battle in round one
> with a knockout ;)

:)

> 1. Global configuration:
> 
> Currently menus (Actions menu, Workflow menu, ...) are configured in
> ZCML and thus immediately available without any installation step.
> 
> For an add-on product this means there is no way to unregister a
> particular menu and menus added this way are available without
> installation as they are global adapters and utilities.

Well, a third party product can of course use a local adapter. This can 
override an existing menu (using the same name), which in turn means 
that it can implement this to return nothing, which would then 
effectively hide it.

> I would suggest to move these registration into the GenericSetup profile
> by using the exportimport handler from GSLocalAddons and thus turning
> these menus into local registrations.

That's possible, though IMHO somewhat overkill since the standard Plone 
menus are standard and probably should be global (e.g. if we change 
them, do we want the hassle of migration?).

The other thing is that the browser:menuItem and browser:menu directives 
do all kinds of non-fun magic in the ZCML registration that we'd have to 
replicate, and I don't know how hard this would be.

> 2. Not-customizable template:
> 
> In CMFPlone/browser/contentmenu we have a new template called
> 'contentmenu.pt'. This replaces the 'global_contentmenu.pt' we had so
> far in the skins folder.
> 
> This template is the first one, that is not put into the CMF skins
> folders and thus not customizable TTW.

Er... I tried to do the dance so that it would be customisable. At least 
the idea was that the view calls back the skin-level template, which 
contains the logic (or maybe it was the other way around, the provider: 
expression is in global_contentmenu, I forget).

This may have gotten lost in the translation, and could be easily 
re-introduced if I messed it up.

> If there is no strong technical reason to not have this in the skins
> folder, I would still put it in there in order not to break our TTW
> development and customization story.

True. I'm actually mainly concerned about existing customisations, since 
we now have a better way of customising going forward. Alec made a valid 
point that this is probably one of the things people should not 
customise templates for (witness how nasty the old template was). I'm +0 
in making it non-customisable and therefore reduce the complexity and 
gain some speed, but it's no problem making it customisable if necessary.

> 3. Minor issues...
> 
> See the COMMENTS.TXT, mainly Martin or anybody else interested in this
> might be able to fix some of those.

I think the JS issue went away anyway (we have a confirmation template). 
It should be simple.

> Summary:
> 
> The branch is in a very good shape, the minor issues should be fixed
> before a merge, but in general this looks like it should make it into
> Plone 3.0.

+1, obviously ;-)

Martin