[Framework-Team] Re: PLIP 244: Portlet management improvements

Danny Bloemendaal 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  
>>> show
>>> on all pages (unless blocked). Currently, people have to use  
>>> contextual
>>> portlets at the root of the site for this, which gets cumbersome  
>>> since
>>> if you block them in one folder, you need to re-add all portlets in
>>> subfolders.
>>
>> This feels like a workaround for the fact that you can not  
>> selectively
>> 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  
> model
> of thinking that the site root is the "parent" of all content from  
> which
> things like portlets can inherit if they need to be site-wide is not  
> how
> 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  
> current
> 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  
much.

>> 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  
>> object.
>
> 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).

Danny Bloemendaal.



More information about the Framework-Team mailing list