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.
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
