Hi Derek,
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.
Ah. CAS is a strange beast. It's actually a separate website that people go to
to authenticate. After they auth, it redirects them back to the originating
website with a ticket that the originating website can verify their identity
with. But at no point does the originating website see their password.
So, the original PloneCASLogin replaced the Login portlet with a new portlet
that just had a button to log in. But this takes up a bunch of screen real
estate for something that is done equally well by the 'login' link on the
personal bar. So, I figure, it'll be an improvement to just remove the portlet
altogether.
If you're working on a generic plug-in, then I don't think that's the
right approach. Whether or not people want that screen real-estate
really should be up to them. Maybe you don't need to make a new portlet
with a big button (though you could), but messing with people's portlets
on install seems a bad idea. The way PAS works, CAS may not be the only
authentication service that's set up, so people may still want the
portlet. That kind of policy really should be up to the site.
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;
Right, that's what I want. Though, if they uninstall my package, then I'd want
to restore the ability to add login portlets. /me makes mental note.
And what if I'm using CAS for some users and regular log-in for other
uses? PAS makes that perfectly possible, but if you nuke the login
portlet that's going to get annoying. :)
> also, I'm not
sure if this would actually remove existing instances of the login portlet.
Aha, I will have to figure out how to do this.
You can't predict where and how people may've assigned portlets. You can
look at the root of the site and remove it from its default location,
but that's about it.
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?
Oh, right. I wasn't clear. PAS4CAS by regebro provides the actual PAS plugin
with no deps on Plone. My package is merely a Plone 3.0 UI adjustment to use
PAS4CAS. So, I think I'm doing exactly what you suggest.
Ah, ok - cool.
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?
So, remove the portlet from being displayed but not remove its definition. Yes,
this would work. I still favor the more comprehensive solution, so that admins
don't think they can just add a login portlet and bypass the CAS redirect. But
perhaps I have too little trust. ;)
/me shrugs
I'm not sure how comfortable I'd be installing a product if I knew it
was going to remove a core part of Plone (even if uninstalling the
package puts it back). I think it'd be easier for everyone if this was
just documented and you left the poor portlet alone. :)
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.
I was thinking this syntax for the XML:
<portlet removename="Login" />
-1
Now you're overloading the <portlet /> directive to have a secondary,
different behaviour.
The way we often do this, is with a remove="True" option on the directive.
<portlet
addview="portlets.Login
remove="True"
/>
(here, title and description would be optional/not used, so I've left
them out). Maybe we need some higher level construct for uninstall though.
That simple. This directive would remove all the instances of the portlet
definition with the given name (specified as 'title' in the addview directive)
and remove the ability to add them to the site.
Eeep! Removing all instances would involve walking the entire site and
be very slow and possibly dangerous.
We currently have no way of adding a portlet assignment with GS - the
<portlet /> directive only adds a new *type* of portlet, not a new
assignment anywhere.
When we get a syntax for adding a specific assignment, it should be
reciprocal so that you can remove a specific assignment as well, but
there can be no syntax for removing any instances anywhere.
If both 'addview' and
'removename' were both present on the same <portlet />, then addview would take
priority and the removename wouldn't fire. What do you think?
If you have conflicts like this, it's better to raise an exception. It's
clearly a programming error by the person who wrote the XML and you
shouldn't guess what they may've meant.
You would need to do this work on a branch, by the way. :)
It looks like it would only affect portlets.py, be a few lines of code, and
would preserve back-compat with the current portlets.xml. Since I *still* have
not sent in my paperwork <duck />, can I just submit a patch?
Sure, but you should get commit access - I'm sure you'll be doing more
of this in the future. :)
Plus, if you have a branch people can actually test and look at, where
you can continue to work after you receive feedback, that's way better
than a patch which is either accepted or rejected wholesale.
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers
