[Framework-Team] Re: PLIP 244: Portlet management improvements
danny.bloemendaal at informaat.nl
Fri Oct 17 11:43:10 UTC 2008
On 17 okt 2008, at 00:39, Martin Aspeli wrote:
> Wichert Akkerman wrote:
>> Previously Martin Aspeli wrote:
>>> - Create a "site wide" portlet category for portlets that should
>>> on all pages (unless blocked). Currently, people have to use
>>> portlets at the root of the site for this, which gets cumbersome
>>> if you block them in one folder, you need to re-add all portlets in
>> This feels like a workaround for the fact that you can not
>> block portlets.
> I used to think that way, I'm not so sure anymore. Speaking to people
> about this over the past few months, I've come to realise that our
> of thinking that the site root is the "parent" of all content from
> things like portlets can inherit if they need to be site-wide is not
> people tend to think about it.
> I think to most people, the root is the front page and is just a page.
> You may want some portlets on the front page, or you may want some
> portlets that are global and show up (almost) everywhere. In our
> model, the "workaround" is that you have to be careful to assign
> portlets to the root and then not block them unduly. This gets
> unnatural, especially if you have deep or complex content hierarchies.
I really don't like this idea. What you suggest is to ditch the
inheritence scheme in the root and introduce it just as hard as soon
as you enter subfolders. From then on, the portlets behave just like
that: a folder inherits the portlets from parent folders. I'd say it
is bad to start treating the root folder differently. Exactly the same
applies for the sharing page and root-local roles. It's a mechanism
that is used so often in different situations. The same applies for
addable types. Please let's not start introducing different schemes.
So a definite -1 for me on this point. I don't think there is a need
for global portlets this way. Each portlet is global in it's own
context (may seem contradictory) unless blocked. As suggested in my
earlier post, allowing to block global portlets makes the entire model
even worse (conceptually and UI wise).
On top of that, what may make things unclear for users even more right
now is that when you do have a index_html for the site root and you
open the portlet manager, you don't manage the portlets on the site
root object but on that index_html. Which doesn't help the user very
>> I would prefer a method where you can both block
>> individual portlets and block only for the current object is, similar
>> to how you propose a flag to only show a portlet in the current
> Right, we need that too. :)
Blocking individual and blocking all portlets in a folder is indeed
something that each have their own use case. Sometimes you want to
know upfront that a certain section in the site never ever inherits
portlets so you know what you have. That's when blocking all porltets
comes at hand. On the other hand, in some situations you may only want
to block one portlet (or redefine like a recent portlet showing only
changes in the current folder while it's parent brothers show changes
in the entire portal).
With a proper interface this doesn't have to be confusing. After all,
blocking individually is just some special form of removing. Combine
it with the remove option in a clever way and you have it solved. And
– once blocked – add a + instead of the x behind it and it restores is
locally or restores the inheritance (depends on whether the parent
folder has it enabled or not).
More information about the Framework-Team