[Framework-Team] Comments on PLIP 244
Hi framework team, I'm sorry I didnt' comment on the previous discussion about PLIP #244, but I wasn't subscribing this list. Anyway, I'd like to comment on some of the objections already posted in the PLIP page. About the usefulness of site-wide portlets, let me give an example: you have a static portlet assignment at a folder, and that portlet makes sense only in the context of that folder, so you want to block it in subfolders but keeping site-wide portlets visible (e.g. like news, review list, events, etc). Currently you can't do this, unless you manage to setup some weird combination using the other categories... Let me also make it clear that the idea here is not to break with existing functionality, neither with any concept. The idea of marking categories as not inherited by subfolders would be extremely useful. Currently, you need to block inheritance in all subfolders. Anyway, I'll be happy to reformulate this PLIP, or even split it into smaller ones, after some more discussion. Thanks, Ricardo ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Comments on PLIP 244
On 28.10.2008, at 11:53, Ricardo Alves wrote: Hi framework team, I'm sorry I didnt' comment on the previous discussion about PLIP #244, but I wasn't subscribing this list. Anyway, I'd like to comment on some of the objections already posted in the PLIP page. About the usefulness of site-wide portlets, let me give an example: you have a static portlet assignment at a folder, and that portlet makes sense only in the context of that folder, so you want to block it in subfolders but keeping site-wide portlets visible (e.g. like news, review list, events, etc). Currently you can't do this, unless you manage to setup some weird combination using the other categories... Let me also make it clear that the idea here is not to break with existing functionality, neither with any concept. The idea of marking categories as not inherited by subfolders would be extremely useful. Currently, you need to block inheritance in all subfolders. Anyway, I'll be happy to reformulate this PLIP, or even split it into smaller ones, after some more discussion. i think the latter would be a good idea, because IMHO there are some good ideas in the plip that are worth implementing in their own right, i.e. point #3: Improve the portlet management screen to show all portlets that can be shown, so users are able to see what's going to be blocked with a category. i'd vote that +1 any time. it would also open the door for blocking portlets not per category (the whole category idea is misguided IMHO in regard to portlets) but per instance. (that might be a separate plip, too) just my $0.02, tom Thanks, Ricardo ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Comments on PLIP 244
Previously Ricardo Alves wrote: Hi framework team, I'm sorry I didnt' comment on the previous discussion about PLIP #244, but I wasn't subscribing this list. Anyway, I'd like to comment on some of the objections already posted in the PLIP page. About the usefulness of site-wide portlets, let me give an example: you have a static portlet assignment at a folder, and that portlet makes sense only in the context of that folder, so you want to block it in subfolders but keeping site-wide portlets visible (e.g. like news, review list, events, etc). Currently you can't do this, unless you manage to setup some weird combination using the other categories... I disagree. Again you are just describing a special case of a more generic problem: the lack of ability to selective block (and perhaps unblock) portlets. I can not think of a single situation where site portlets would make sense. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Comments on PLIP 244
Wichert Akkerman wrote: Previously Ricardo Alves wrote: Hi framework team, I'm sorry I didnt' comment on the previous discussion about PLIP #244, but I wasn't subscribing this list. Anyway, I'd like to comment on some of the objections already posted in the PLIP page. About the usefulness of site-wide portlets, let me give an example: you have a static portlet assignment at a folder, and that portlet makes sense only in the context of that folder, so you want to block it in subfolders but keeping site-wide portlets visible (e.g. like news, review list, events, etc). Currently you can't do this, unless you manage to setup some weird combination using the other categories... I disagree. Again you are just describing a special case of a more generic problem: the lack of ability to selective block (and perhaps unblock) portlets. I agree that per-portlet blocking would make it easier, and it shouldn't be that hard to implement. I can not think of a single situation where site portlets would make sense. The use case is almost the same, even with per-portlet blocking. I'll try to describe it. Say you have the following site structure: / (Site Root) /services (Folder) /services/network/ (Folder) - the site root has a portlet assignment (e.g. news portlet) - the folder /services blocks the news portlet - but you don't want to block the news portlet in folder /services/network - if using a site-wide portlet, folder /services would be the only one blocking it and it would be shown in /services/network. Anyway, I do agree that this use case is not that common, and per-portlet blocking would do the trick for most use cases. So I guess the best is to start working on it :) Ricardo -- Ricardo Alves [EMAIL PROTECTED] Eurotux http://www.eurotux.com ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
