[Framework-Team] PLIP 242: Move manage-portlets link to site actions
I'm too late for my own deadline, so I have no expectation that the framework can review this on time time. If you guys have a bit of spare time I would appreciate it though :) I want to propose PLIP 242 for Plone 3.3: Move manage-portlets link to site actions. Motivation == Both portlet columns feature a manage portlets link at the bottom. This has several problems: * the location of the link and the fact that each column has its own manage portlet link leads users to believe that that link will go to a page to configure that specific column, which is not true. * Many (if not most)l custom themes style the portlet column and have no room for the manage portlets-link below the portlets. * all configuration options are in site or document actions, except for manage portlets- a needless inconsistency. Proposal Remove the manage portlets-link from the default portlet renderer template and replace it with a site action. 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
[Framework-Team] PLIP 231: Optionally copy roles from parent when blocking inheritance
Another one from Danny.. http://plone.org/products/plone/roadmap/231 Optionally copy roles from parent when blocking inheritance 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] PLIP 323: Resource Registries Improvements
Previously Raphael Ritz wrote: I think we have this on the radar already (seeing comments from most team members on the plip page) The framework team desparately needs someone who coordinates things and keeps lists of PLIPs that are being reviewed. I hope that the team can elect someone to take that role during their meeting this week. 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
[Framework-Team] Forgotten PLIPs
There appear to be a fair number of PLIP that are marked as being proposed but never made it to this list. I would like to encourage the framework team to take a look at the current list of PLIPs and see if there are any that should be rejected or should be considered for 3.3 or 4.0. 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] PLIP 242: Move manage-portlets link to site actions
Raphael Ritz wrote: Wichert Akkerman wrote: I'm too late for my own deadline, so I have no expectation that the framework can review this on time time. If you guys have a bit of spare time I would appreciate it though :) Hi Wichert, don't worry too much. At least I planned to start reviewing only after the conference sprints. I want to propose PLIP 242 for Plone 3.3: Move manage-portlets link to site actions. While I think I see your point I'm not sure it's the right place to move it to. First, I agree that the current situation isn't perfect. But: those assignments are context depended and site actions are typically used for (site) global settings. Now while you can always link to the right URL, of course, I'm not sure that that would be less confusing. From this POV the document actions might be more appropriate, don't know. Or some new, location specific management category could be introduced which could also be home for some of the things we currently put on the edit form for lack of a better place (like 'exclude from navigation' to give one example). I did mention that on the web-version of the PLIP. Site actions works since it mostly contains rarely-used items, which includes manage portlets. But you are very correct in that document actions would technically be more correct. 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
[Framework-Team] PLIP 236: Move Display menu to edit and allow for custom properties
I think Danny wanted to propose this for 3.3 but forgot to mail this list? The workflow status shows that he proposed it. Motivation == The display menu is a setting that controls how an object presents itself to the user. Right now it suggests it is a switch that every user can change at will not knowing it is persistent among all the users. Therefore this menu should be part of the settings tab in the edit form. Assumptions Proposal First: remove the Display menu and add a field to the settings tab of the edit form where it belongs. Second: a Display view should be able to provide a custom property sheet that is loaded into this settings form whenever you pick a display type. These properties give the user options to set parameters for the chosen view. A thumbnail view for instance could provide an option telling how many thumbs are shown. The point is that you don't know this in advance so the view should somehow provide this property sheet. -- 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] PLIP 242: Move manage-portlets link to site actions
Wichert Akkerman wrote: I'm too late for my own deadline, so I have no expectation that the framework can review this on time time. If you guys have a bit of spare time I would appreciate it though :) Hi Wichert, don't worry too much. At least I planned to start reviewing only after the conference sprints. I want to propose PLIP 242 for Plone 3.3: Move manage-portlets link to site actions. While I think I see your point I'm not sure it's the right place to move it to. First, I agree that the current situation isn't perfect. But: those assignments are context depended and site actions are typically used for (site) global settings. Now while you can always link to the right URL, of course, I'm not sure that that would be less confusing. From this POV the document actions might be more appropriate, don't know. Or some new, location specific management category could be introduced which could also be home for some of the things we currently put on the edit form for lack of a better place (like 'exclude from navigation' to give one example). What do others think? Raphael Motivation == Both portlet columns feature a manage portlets link at the bottom. This has several problems: * the location of the link and the fact that each column has its own manage portlet link leads users to believe that that link will go to a page to configure that specific column, which is not true. * Many (if not most)l custom themes style the portlet column and have no room for the manage portlets-link below the portlets. * all configuration options are in site or document actions, except for manage portlets- a needless inconsistency. Proposal Remove the manage portlets-link from the default portlet renderer template and replace it with a site action. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 242: Move manage-portlets link to site actions
Wichert Akkerman wrote: I did mention that on the web-version of the PLIP. Site actions works since it mostly contains rarely-used items, which includes manage portlets. But you are very correct in that document actions would technically be more correct. Not all views include document_actions, though. As mentioned, I'm -1 on moving it anywhere (visually) other than where it is currently in a 3.x release. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 323: Resource Registries Improvements
Wichert Akkerman wrote: A PLIP from Michael Dunlap and Florian Schulze which is marked as being propsed in its workflow state but apparently not mailed to this list (I sense we need a content rule for this stuff..) after the upgrade to Plone 3 ;-) (and once the trigger on workflow state changes works reliably again) http://plone.org/products/plone/roadmap/232 Allow Resource Registries to use conditional comments for CSS to bring the IEFixes.css into the registry and allow external references to resources for all registries. I think we have this on the radar already (seeing comments from most team members on the plip page) Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: PLIP 236: Move Display menu to edit and allow for custom properties
Wichert Akkerman wrote: First: remove the Display menu and add a field to the settings tab of the edit form where it belongs. -1 for 3.x. - This breaks existing documentation and expectations. - The display menu is not specific to Archetypes or any particular content type implementation. We shouldn't tie this to AT (or any other content type framework). I think we should revisit this for 4.x, though. I agree that it belongs on the edit screen. In fact, we looked at doing that for 3.0, but decided it wasn't worth it for the reasons above. Second: a Display view should be able to provide a custom property sheet that is loaded into this settings form whenever you pick a display type. These properties give the user options to set parameters for the chosen view. A thumbnail view for instance could provide an option telling how many thumbs are shown. The point is that you don't know this in advance so the view should somehow provide this property sheet. That'd be really nice. Ironically, that's easier to do if we keep it in the menu (or you'd need pop-ups or complex widgets on the edit screen). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 323: Resource Registries Improvements
On Thu, Oct 9, 2008 at 12:54, Raphael Ritz [EMAIL PROTECTED] wrote: Yup, I guess most of us consider Andy to be that one but I know he sees this differently. Anyone from the team willing to take this on? /me steps back smartly. I won't be able to take this; as it is I am hardly covering all my current responsibilities. -- Martijn Pieters ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] PLIP #MIA - z3c.autoinclude
Hi,
Ethan Jucovy wanted to propose a PLIP for 3.3, which I've seconded. He
has been having problems with plone.org and his laptop, but the text is
pasted below. We'll get it moved to a real PLIP soon, but I'd appreciate
it if you could review it.
Cheers,
Martin
Automate ZCML Loading for Plone Plug-ins
Enable automatic plugins for Plone with z3c.autoinclude
Definitions
===
autoinclude: ``z3c.autoinclude``, a package
(http://pypi.python.org/pypi/z3c.autoinclude) for automatically
including ZCML files from dependencies and plugins.
Plugin package: a package providing some extended functionality to Plone
activated by execution of ZCML configuration.
Motivation
==
Installation of packages that extend Plone's functionality is currently
somewhat burdensome. Most extension packages will provide ZCML that
must be loaded in order for the package to function properly. The
standard way of installing these plugin packages is to use ZCML slugs in
the package-includes directory, typically marked in a buildout.cfg file
for replicability. However, this is a burdensome process: editing the
installed plugins involves editing the buildout.cfg file and re-running
buildout, or adding and removing symlinks and files on the filesystem;
there is no straightforward way to share different permutations of
plugins without making nearly identical copies of buildout.cfg files;
and the process involves unnecessary repetition of package names as
requirements and plugins, a subtlety that integrators, particularly
beginners, might easily overlook. A more automated and implicit system
of loading plugins would eliminate this error-prone process.
Assumptions
===
Packages signal to autoinclude that they are plugin candidates by
setting a setuptools ``entry_point``, so plugin packages must be
packaged as setuptools eggs.
Proposal
Explicitly invoke autoinclusion of plugins for Plone. This would look like:
``includePlugins package=plone.app /``
at the end of the CMFPlone/configure.zcml file, within the configure
directive.
Plugin packages would then signal that they should be included by adding
{{{
setup(...
entry_points=
...
[z3c.autoinclude.plugin]
target = plone.app
...)
}}}
to their setup.py file.
Implementation
==
See Proposal above.
Deliverables
See Proposal above.
Risks
=
autoinclude computes the packages to include at Zope startup, when each
include* directive is executed, so it slows down the startup time.
The execution time of the algorithm used is dependent on the number of
entries in ``sys.path``, so this slowdown may become unacceptable in
environments with many eggs installed. This can be mitigated by future
improvements in z3c.autoinclude like optimizations to the algorithm or a
freeze script to compute autoinclusion packages once and output to a
ZCML file.
Progress log
Participants
Ethan Jucovy
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 242: Move manage-portlets link to site actions
On 9 okt 2008, at 11:29, Martin Aspeli wrote: Wichert Akkerman wrote: I did mention that on the web-version of the PLIP. Site actions works since it mostly contains rarely-used items, which includes manage portlets. But you are very correct in that document actions would technically be more correct. Not all views include document_actions, though. As mentioned, I'm -1 on moving it anywhere (visually) other than where it is currently in a 3.x release. Martin Well, first of all: we really have to be restrictive for doing -1's just because there is documentation describing it. That will nearly always stop progress and we won't that to happen. Second: there is really a problem with how it is done now. It's not only ugly but it is also showing all the time while in 99% of the page- visits you don't need to see that link at all. How many times do you want to change the config of the portlets? Also, when you do, why have these manage links shown twice? Once you enter the manage page, you can control all column configurations, not just the one you clicked on. It adds unnecesary noise. It is like always leaving that flap on the front of your tv set open that allows you to configure your channels. It's annoying and distracting. I tend to agree with Wichert in this in that moving it away from the main parts of the page makes it ends up in a place that is... well.. out of the way. Semantically of course it is not a site action so yes, that is a valid point against it and document actions seems like a good second alternative but if they aren't always showing then you have a problem as well. So, then how would you solve this issue then? How can we close the flap when we don't need it to be open? I think that eventhough it is not a site action (which user does know what a site action is anyway??) it best fit with them. It is configuration and manu links that have a relationship with configuration are found there (prefs, site setup, etc). From that point of view it is not strange to have it there. So, until in 4.0 where this may not be an issue anymore, I'm +1 on this one. Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 238: Disable inline editing by default
On 27 sep 2008, at 16:15, Wichert Akkerman wrote: I want to propose PLIP 238: Disable inline editing by default Motivation -- I suspect that by now most of us have realized that the current inline editing behaviour in Plone 3 is not very practical. It has two main problems: * it is very easily triggered by default, which causes unwanted edit fields to be opened which have to be manually closed. This happens because many, if not most, people click accidentily, select text to keep track of the reading position, try to select text to copypaste it or for other reasons. Since every single click activates inline edit this happens all too often and becomes very frustrating over time. I think that it's not caused by inline editing but by a bad UI choice here. I never ever understood why it was triggered by a single click. For me that is the only reason why I have this disabled in our intranets. I think that when done right this could still work well. So even if you make it optional, when enabled it should be done properly. I suggest–when enabled–that it doesn't trigger on single click but by clicking on a tiny icon that shows up next to the field when hovering over the field's value. Simple, unobtrusive and predictable. You could even do a fade-in on hover so that you don't see it when moving over the page. * as Alexander mentioned in his new UI proposal what you really want is a quick option to go to a full edit-mode. Editing a single field is a much less common operation than we were expecting. Yes, maybe but as we say in The Netherlands: a lot of water will have flown through the Rhine before that will have happened. In the mean time this could work as intentended. Proposal - Current Plone releases have a simple toggle to enable or disable inline editing. I propose that we change the default for newly created sites to disabled. My counter proposal is to make it optional and when enable refactor the trigger as described above. Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 228: Restore 'Add Item..' menu on all pages
On 28 sep 2008, at 07:47, Martin Aspeli wrote: Wichert Akkerman wrote: I guess I'm the first one. I want to propose PLIP 228 for Plone 3.3. I feel that removing the removal of the 'Add Item' dropdown in many places in Plone 3 is a regression in behaviour, and makes adding content a lot more cumbersome. The PLIP has so far only received positive responses from several people. The full PLIP can be found here: http://plone.org/products/plone/roadmap/228 Perhaps we could make it optional? I'm not normally one for having too many options in the UI, but I know that some people were quite confused about the old behaviour too. It looks as if you can add a page to a page when you see the Add new menu on a page, and it blurs the distinction between folderish and non-folderish objects. For example, I've seen people who expect that if they're looking at /path/to/a-page and they add a new page using the add new menu, they expect the URL to be /path/ to/a-page/another-page. I tend to believe that with proper wording you solve the problem. Just thinking out loud: When in a folder: Add new... When in a 'Page': Add new sibling... Not sure exactly but when chosen right I think you could reinstate the menu in all places. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #126: Link type should automatically redirect when accessed directly
It seems that this plip has a few valid comments that seem to extend it. What will the plip exactly be? Is it only about direct linking or also a better way to use it to link internally? For the latter you could imagine a different widget that either uses the yet-to-come überselectionwidget to pick an object or manually enter a remote link. For the first proposal I'd say to use a setting in the site props that controls if you really want this direct linking. In intranets you could easily see Links as sort of landing pages where you go to to read about the link, discuss it and eventually folllow the link. In our intranet we have several sitations that utilize this use case. We even extended the Link with a thumb preview and instructions how to log in to the remote site. They were used as example websites that sometimes are restricted and need extra instructions. It would really be a pain to customize the navtree only to restore this behaviour. So: +1 on both but configurable properly. And for symlinks.. there's already a product that does this a little: SimpleAlias. (Forgot who wrote that thing). On 3 okt 2008, at 01:24, David Glick wrote: I've edited an old PLIP that I'd like to propose for 3.3: http://plone.org/products/plone/roadmap/126 This is about making the built-in Link content type redirect to its target when the link is accessed by a direct URL (not just when it appears as a link in navigation). Note that some of the discussion of the PLIP relates to other Link- related proposals which appeared in an earlier revision of the PLIP (but which have been already incorporated into Plone and thus edited out of the PLIP.) David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org [EMAIL PROTECTED] work: (206) 286-1235 x32 mobile: (206) 679-3833 Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup ___ 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] PLIP 241: Clean up auto-sort, auto-order code
Sounds good but for my understanding could you please give me more info and refresh my memory of what this sorting was for originally? On 5 okt 2008, at 16:47, Andreas Zeidler wrote: hi, i'd like to propose PLIP 241[*] for plone 3.3: removing the unused auto-sorting, -ordering code would safe a few hundred lines of code and help slimming the current code base a little bit. of course i'll need to write a bit more, but will try to do this on the plane to dc tomorrow. unfortunately i didn't have the time before proposal deadline, but wanted to give a heads-up anyway... cheers, andi [*] http://plone.org/products/plone/roadmap/241 -- zeidler it consulting - http://zitc.de/ - [EMAIL PROTECTED] friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.1.5.1 released! -- http://plone.org/products/plone/ ___ 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] PLIP #240: Improve locking configurability
On 6 okt 2008, at 03:22, Raphael Ritz wrote: David Glick wrote: I'd like to propose PLIP #240 for inclusion in Plone 3.3: http://plone.org/products/plone/roadmap/240 This PLIP is intended to provide several avenues toward addressing the problem of content accidentally getting left in a locked state. +1 for this, although: David Glick is willing to serve in an advisory role to whoever is willing to implement this. I suspect this means that it won't get implemented. :) I think you need to find someone who's willing to commit to delivering it, or it won't happen. I suppose I should clarify. I'm willing to commit to implementing this if it's just a matter of changing the default timeout and adding some KSS to keep the lock in place while an item's being edited. In an effort to avoid overextending myself, I'm not able to commit to creating a new locking configlet (though based on Sidnei's comment about the PloneLockManager product, which I was unaware of, that may be less important). I don't recall why it never made it into the release but when Jeff and I started the locking integration at the Archipelago sprint a few years ago we did consider it and created https://svn.plone.org/svn/collective/LockManager/branches/plip_145_TTWLocking/ There shouldn't be much missing I hope. Just so this won't get forgotten ... Raphael Then this really should be added asap. I too see locks showing up everywhere. There must be a sane timeout indeed and I also recalled during that sprint that it was taken into account. Wasn't the beforeunload event in the browser used to unlock it? +2 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 236: Move Display menu to edit and allow for custom properties
On 9 okt 2008, at 11:32, Martin Aspeli wrote: Wichert Akkerman wrote: First: remove the Display menu and add a field to the settings tab of the edit form where it belongs. -1 for 3.x. - This breaks existing documentation and expectations. Mmm.. change the docs then ;-) - The display menu is not specific to Archetypes or any particular content type implementation. We shouldn't tie this to AT (or any other content type framework). Who is talking about that? An end user has no notion of AT whatsoever! He sees a settings tab in the edit form and there is where this option needs to be. (Just like wf-transitions need to be part of the form and they aren't related to AT either). Right now I see the display setting of certain folders change almost on a daily basis becuase people think they can use it to fit there current, temporary needs. And I can't blame them. That thing is wrong there. There are a lot more attributes/properties on AT objects that control settings. Why not add the Display value as well to the object? You give it the settings schemata value and you are done. You only have to change the lookup code (with a fall back to the old location where origionally the display value was stored if it is there while the field is still None so you don't need any migration). Just be creative ;-) Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
