Hiding a Portlet in a Filesystem Package

Martin Aspeli optilude at gmx.net
Tue Oct 16 22:51:28 UTC 2007


Derek Richardson wrote:
> Hey. I'm writing a package to provide a Plone 3.0-compatible UI for PAS4CAS - a 
> replacement for PloneCASLogin, which has not been updated. The basics work. I 
> now want to hide the login portlet, since it is non-functional and confusing 
> with CAS.

Really? Why? If CAS (what is it?) means you're always logged in, then 
the portlet shouldn't show up anyway (it only shows up for anonymous); 
if CAS requires some kind of explicit log in/log out, then you could 
customise/override/supplement the login portlet with that action.

> I'm in a filesystem package, so my first thought was to remove the portlet using 
> GenericSetup. Alas, no luck - the handler in plone.app.portlets seems to only 
> support adding portlets, not removing them. I'm contemplating extending this 
> handler to remove portlets, as well. I'd then put the extended handler in my 
> product and submit a patch for plone.app.portlet.

Being able to remove portlets in the GS handler would be nice (and the 
GS handler needs more work, as we've talked about before). However, this 
is a bit extreme - it won't be possible to add a new login portlet 
anymore once the portlet has been uninstalled like this; also, I'm not 
sure if this would actually remove existing instances of the login portlet.

I'd say that this is not really something that belongs in a package that 
contains a PAS plug-in, by the way. The PAS plug-in ought to be generic 
enough not to have dependencies on Plone specifics such as the portlets 
implementation. Perhaps a higher level package that had the PAS4CAS 
package as a dependecy could contain this instead?

> Questions:
> 
> 1 - Is there a better way to hide the login portlet from a filesystem package 
> than to do it through GenericSetup?

You could just remove the assignment from the root of the site?

> 2 - If I patch the portlet handler, is this likely to be accepted back? If so, 
> what is the first plone version in which it is likely to be allowed in? I must 
> admit, I'm a little confused by 3.0.x vs 3.1 vs 3.5/4.0 and what is allowed in 
> each. ;)

If you extend, rather than change the handler, it'd be a good candidate 
for 3.1.

You would need to do this work on a branch, by the way. :)

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book





More information about the Product-Developers mailing list