[Remember Mailing List] is it possible to substitue a custom template for a standard plone configlet?

[ken manheimer]

I'm cleaning up Products.remember, and want to make the way it changes the Site Setup Users and Groups (@@usergroup-userprefs) configlet less disruptive.  In general, can products substitute different page templates for standard Site Setup configlets without permanently changing it for all portals in the zope instance?

The latter is what Products.remember is currently doing, replacing the standard usergroup-userprefs template with its own via an overrides.zcml.  There are two big problems with this - it affects all the portals in the Zope instance, whether or not Products.remember is quick-installed, and it is permanent, lasting after Products.remember has been removed entirely from the system.

Since I don't know why that approach was taken, i'm unsure about whether less disruptive approaches would work.  Don't products sometimes have to offer different versions of standard control panel configlets?  What's the right way to do it?

Guidance would be greatly appreciated!  I've checked in several Products.remember fixes to the collective, including Plone 4 and Products.membrane 2 compatibility, integration of someone else's email-login provisions, a substantial part of uninstallation, and more.  This, plus an upgrade step to undo the effects of the overrides.zcml, are the main obstacles i'm facing before packaging up the changes for release.

Ken Manheimer

--
Archive: http://www.coactivate.org/[…]/1306432078173
To unsubscribe send an email with subject "unsubscribe" to reme...@lists.coactivate.org. Please contact remember...@lists.coactivate.org for questions.

[Maurits van Rees]

Op 26-05-11 19:47, ken manheimer schreef:

> I'm cleaning up Products.remember, and want to make the way it changes
> the Site Setup Users and Groups (@@usergroup-userprefs) configlet less
> disruptive. In general, can products substitute different page
> templates for standard Site Setup configlets without permanently
> changing it for all portals in the zope instance?
>
> The latter is what Products.remember is currently doing, replacing the
> standard usergroup-userprefs template with its own via an
> overrides.zcml. There are two big problems with this - it affects all
> the portals in the Zope instance, whether or not Products.remember is
> quick-installed, and it is permanent, lasting after Products.remember
> has been removed entirely from the system.

I have not looked at the code, but I find this part hard to believe. If
Products.remember is removed from the system then its overrides.zcml
cannot be loaded anymore so the default behavior returns, right?

> Since I don't know why that approach was taken, i'm unsure about
> whether less disruptive approaches would work. Don't products
> sometimes have to offer different versions of standard control panel
> configlets? What's the right way to do it?

This approach was probably taken because it is the easiest approach:
just assume there is only one Plone Site and that no one adds
Products.remember unless he really wants to install and use it.

The usual way to get more control over this, is by moving whatever is in
the overrides.zcml to a normal configure.zcml and registering it for
your own browser layer (see the plone.browserlayer package).

> Guidance would be greatly appreciated! I've checked in several
> Products.remember fixes to the collective, including Plone 4 and
> Products.membrane 2 compatibility, integration of someone else's
> email-login provisions, a substantial part of uninstallation, and
> more. This, plus an upgrade step to undo the effects of the
> overrides.zcml, are the main obstacles i'm facing before packaging up
> the changes for release.

Great, thanks!

--
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/

--
Archive: http://www.coactivate.org/projects/remember/lists/remember/archive/2011/05/1306434496270

[ken manheimer]

On Thu, May 26, 2011 at 2:28 PM, Maurits van Rees <m.van...@zestsoftware.nl> wrote:

Op 26-05-11 19:47, ken manheimer schreef:

I'm cleaning up Products.remember, and want to make the way it changes the Site Setup Users and Groups (@@usergroup-userprefs) configlet less disruptive.  In general, can products substitute different page templates for standard Site Setup configlets without permanently changing it for all portals in the zope instance?

The latter is what Products.remember is currently doing, replacing the standard usergroup-userprefs template with its own via an overrides.zcml.  There are two big problems with this - it affects all the portals in the Zope instance, whether or not Products.remember is quick-installed, and it is permanent, lasting after Products.remember has been removed entirely from the system.

I have not looked at the code, but I find this part hard to believe.  If Products.remember is removed from the system then its overrides.zcml cannot be loaded anymore so the default behavior returns, right?

You're probably right - I'm certainly not certain about that part.  I did notice that removing the overrides.zcml setting from my product and uninstalling didn't wipe out the setting (nor did reinstalling the product, after that), and figured from there that there was some kind of persistent registry.  (I am confused about what configuration persists beyond presence of the product and what depends on the product's being installed, particularly when it comes to the interface machinery.)  I didn't check very carefully, but will have to in order to determine whether i actually need to make an upgrade step to wipe clean it up - it'd be great if not.

 

Since I don't know why that approach was taken, i'm unsure about whether less disruptive approaches would work.  Don't products sometimes have to offer different versions of standard control panel configlets?  What's the right way to do it?

This approach was probably taken because it is the easiest approach: just assume there is only one Plone Site and that no one adds Products.remember unless he really wants to install and use it.

Makes sense, but distressing.

The usual way to get more control over this, is by moving whatever is in the overrides.zcml to a normal configure.zcml and registering it for your own browser layer (see the plone.browserlayer package).

Yay!  Thanks!

(I've failed to find how layer precedence is organized, much less adjusted, but i'll look into that if it turns out that the default behavior isn't what i need.)

Ken

 

Guidance would be greatly appreciated!  I've checked in several Products.remember fixes to the collective, including Plone 4 and Products.membrane 2 compatibility, integration of someone else's email-login provisions, a substantial part of uninstallation, and more.  This, plus an upgrade step to undo the effects of the overrides.zcml, are the main obstacles i'm facing before packaging up the changes for release.

Great, thanks!

--
Maurits van Rees
Web App Programmer at Zest Software: http://zestsoftware.nl
Personal website: http://maurits.vanrees.org/ 

--
Archive: http://www.coactivate.org/[…]/1306438946498