Re: [Framework-Team] PLIP revisions for #126 and #240
On 7 feb 2009, at 19:39, David Glick wrote: Andrew and I have made a few revisions to PLIPs #126 (link improvements) and #240 (TTW locking configuration) based on the initial review feedback. Notes on the changes can be found at the bottom of the respective PLIP_xxx_README.txt files in the review buildouts for each of these PLIPs. peace, Ok, I revisited this plip and it looks good now. So +1 for me on this one. Danny. PLIP 126 framework review #3 by Danny Bloemendaal, 2009-02-11 = Reviewed this plip after some changes have been made and the behaviour is now much more predictable. +1 on this for merging.___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP review deadline has passed - time to review!
On 20 jan 2009, at 23:08, Martijn Pieters wrote: On Tue, Jan 20, 2009 at 21:43, Andreas Zeidler a...@zitc.de wrote: Do whatever you feel is right considering that I missed the deadline. personally i think it'd be stupid to not consider changes that were ready for a while now. i mean, yes technically you missed the deadline, but to me i makes a subtle difference if you the code isn't quite ready yet or if only the notification mail went missing — somehow :). anyway, i'm +1 on considering the bundle. Same sentiment here, +1 from me to include it in the review. A bit late but for the record a +1 from me as well. Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #126 ready for review
Ok, I reviewed this plip and these are my findings: PLIP 126 framework review #3 by Danny Bloemendaal, 2009-01-27 = review steps the bundle was reviewed on OSX 10.5.6 doing the following: * bundle checkout, buildout etc * manual function tests to verify things work as intended notes and observations -- I reviewed this plip from a UI perspective of course. So I started by creating a folder as admin with a Link in there. Published both items. In another browser I visited as an anonymous user and opened the folder. Both the navtree and the link redirected me to the target url. As admin I also visited the folder and the navtree links me to the Link object while the folder listing redirects me to the target url. I checked what the default setting is for this redirecting and Redirect immediately to link target was not checked. Then how is it possible that it does redirect for anonymous and for admin in the folder listing? In my opinion, if you offer this option then it should not redirect when unchecked. Checking the option doesn't seem to change anything for anonymous and logged-in users without edit permissions. It keeps redirecting. The only change I notice when checking this option is the portal-like info message in the landing page for the Link object. So it looks as if this feature is not working at all or I am missing the entire point (which is also bad because I'm doing what I actually do best: being a dumb user) Seeing this and at least thinking about the intentions I begin to wonder why this isn't implemented as the comments option. There you have a site setting for the type if you want to allow commenting or not. If allowed you can still overrule this for each instance (you can either user the site's default or control locally). I also am not in favor of the Info message. I'd leave it out. If the site admin or the site designer decided to do automatic linking, then you don't need to show this decision in every view page. I'd put in the edit form instead where it belongs. It's a setting after all. Conclusion -- It seems to not work so for now (until someone explains me what I'm doing wrong and if so why I misinterpreted the entire functionality): -1 On 26 jan 2009, at 00:52, Andreas Zeidler wrote: On Jan 13, 2009, at 1:37 AM, David Glick wrote: PLIP 126 (Link type should automatically redirect when accessed directly) has been implemented. i've added my review notes in http://dev.plone.org/plone/changeset/24687 in short: very nice, +1 for merging. thanks david and andrew! cheers, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.1.7 released! -- http://plone.org/products/plone/ PGP.sigATT1.txt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #126 ready for review
On 27 jan 2009, at 20:19, Danny Bloemendaal wrote: As admin I also visited the folder and the navtree links me to the Link object while the folder listing redirects me to the target url. An additional remark. I notice the consideration in the readme for not adapting the various views that have conditions like folder_listing. I don't agree with the choice not to change them. If you give the option to have this redirecting or not, I'd say you *have* go all the way. Right now it is confusing because it only works partially. That doesn't feel right at all. You either do it right or leave it as it is now in my opinion. So, for this choice alone i tend to give it a -1. On 26 jan 2009, at 00:52, Andreas Zeidler wrote: On Jan 13, 2009, at 1:37 AM, David Glick wrote: PLIP 126 (Link type should automatically redirect when accessed directly) has been implemented. i've added my review notes in http://dev.plone.org/plone/changeset/24687 in short: very nice, +1 for merging. thanks david and andrew! cheers, andi -- zeidler it consulting - http://zitc.de/ - i...@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 3.1.7 released! -- http://plone.org/products/plone/ PGP.sigATT1.txt ___ 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 #126 ready for review
On 27 jan 2009, at 21:07, David Glick wrote: On Jan 27, 2009, at 11:19 AM, Danny Bloemendaal wrote: notes and observations -- I reviewed this plip from a UI perspective of course. So I started by creating a folder as admin with a Link in there. Published both items. In another browser I visited as an anonymous user and opened the folder. Both the navtree and the link redirected me to the target url. As admin I also visited the folder and the navtree links me to the Link object while the folder listing redirects me to the target url. I checked what the default setting is for this redirecting and Redirect immediately to link target was not checked. Then how is it possible that it does redirect for anonymous and for admin in the folder listing? In my opinion, if you offer this option then it should not redirect when unchecked. Checking the option doesn't seem to change anything for anonymous and logged-in users without edit permissions. It keeps redirecting. The only change I notice when checking this option is the portal-like info message in the landing page for the Link object. So it looks as if this feature is not working at all or I am missing the entire point (which is also bad because I'm doing what I actually do best: being a dumb user) This behavior is due to the decision that I made and noted in the PLIP readme: * I experimented with, but ultimately deferred removing the conditional code in many listing views that handles Links as a special case in order to link to the target URL. This becomes unnecessary if redirect_links is true, because you can go to the Link like any other content type and its default view will take care of redirecting to the target. However, setting redirect_links to True seemed like too big of a behavior change for the 3.x series, so I have instead added a draft PLIP suggesting this change for 4.x: http://dev.plone.org/plone/ticket/8867 So, as the PLIP is currently implemented, the Redirect immediately to link target setting does not affect the behavior when Links appear in navigation. Danny, you're right that this is confusing and it's bad that the control panel setting doesn't seem to have an effect. Well, it was all about expectation (and probably not having read the readme correctly although having read the plip twice and I didn't see that it was just for redirecting when you access the url directly and not through the various navigation tools. The desired behavior we'd like to have is that links redirect, or don't redirect, based on the setting in the control panel, regardless of how someone accessed the link. Indeed. You need to make the behaviour predictable for the editors/ administrators. The tricky question is what to do with existing sites that are expecting certain behavior in the 3.x series. That behaviour was 'broken' to begin with. But ok... If we make everything be controlled by the Redirect immediately to link target setting, then we cannot set it to True without changing the behavior when links are accessed via a direct URL. But we cannot set it to False without changing the behavior when links appear in navigation. However, at the moment it seems to me that the former would have been a better option, since Links are more often accessed via navigation than via a direct URL. So I probably made a bad decision when implementing this PLIP. I'd say that when the switch is off, it behaves as 3.3. So, redirect=off, no redirect occures at all. When redirect=on everything redirects: direct urls, navigation elements, lists etc. At least that makes it predictable. At this point I would like to change the PLIP implementation to: 1. re-add the changes I made to listings so that Links aren't handled specially, and the redirect behavior is handled by the link view rather than by the navigation generating logic This makes it way much easier to customize the entire Link behaviour. 2. change the default value of the Redirect immediately to link target setting to True, so that the behavior as viewed by the end user of clicking on a link in navigation remains the same 3. add documentation of how to restore the existing pre-3.3 behavior (links in navigation redirect, but Links when accessed via a direct URL do not) by changing the default view for Links back to link_view instead of the new link_redirect_view which contains the logic that checks the configlet setting. Sounds ok with me. But I'm not sure whether the PLIP process allows me to make changes at this point... You have my vote. /me looks at the others Seeing this and at least thinking about the intentions I begin to wonder why this isn't implemented as the comments option. There you have a site setting for the type if you want to allow commenting or not. If allowed you can still overrule this for each instance (you can either user the site's default or control locally). I didn't do it this way because it seemed
Re: [Framework-Team] PLIP #240 ready for review
Ok, I reviewed this plip and did some tests with ttw locking and indeed it seems to work. I leave all the technical review stuff to people with brains. I have a remark for the help text below Enable locking for through- the-web edits though. I think that the line Disabling locking here will only affect users editing content through the Plone web UI. Content edited via WebDAV clients will still be subject to locking. by itself isn't explaining much what this setting does. I want to know why I would want to enable or disable this option. So a +1 but please add a bit more explanation to the switch in site props. On 17 jan 2009, at 00:04, Andrew Burkhalter wrote: PLIP 240 (Improve locking configurability) has been implemented. You can get the review buildout from: https://svn.plone.org/svn/plone/review/plip240-locking-improvements/ I'm going to paste the contents of https://svn.plone.org/svn/plone/review/plip240-locking-improvements/PLIP_240_README.txt below for ease of any discussion. Please take careful note of the Other section below. Thanks! Andrew (sending on behalf of David) PLIP 240: Improve locking configurability = This review buildout presents the changes that have been made in order to implement PLIP 240. The goal of this PLIP is to give more flexibility in configuring Plone's lock-on-edit behavior. One of the original aims of this PLIP was to reduce the pain that has been occurring in the Plone 3.x series when items get inadvertently locked and then accidentally left in that state. A late-October fix in Archetypes (http://dev.plone.org/archetypes/changeset/10163, which made it into Plone 3.2) already helped greatly with this by making sure that the unlockOnFormUnload.js script also runs for inline edits. However, that script doesn't work in Webkit-based browsers, nor in case of things like browser crashes. So we have gone ahead with the plan to change the default lock timeout to 5 minutes and keep it alive via a periodic AJAX call, as well as adding a global lock-on-edit on/off switch. The unlockOnFormUnload.js also continues its old behavior, as it is still useful when it works. Summary of changes -- * plone.locking: - Changed the default timeout for through-the-web locks to 10 minutes. - Added a refresh_lock method to the ILockable interface and to the default implementation, TTWLockable - Added a publishable refresh_lock method to the plone_lock_operations browser view - Made the lock method from ITTWLockable check the lock_on_ttw_edit setting * Plone: - Added lock_on_ttw_edit property to site_properties, with a default value of True to match the behavior of Plone 3.3 - Adjusted unlockOnFormUnload.js to also call the refresh_lock method every 5 minutes (for forms with the enableLockProtection class only) - Make sure the 'removeLockProtection' KSS action fires when someone cancels inline editing, to stop calling the periodic refresh_lock * plone.app.controlpanel: - Added 'Enable locking' setting to the site configlet, which adjusts the lock_on_ttw_edit property - Changed the SiteControlPanelAdapter to also adapt ILockSettings from plone.locking so that plone.locking can look up the value of the setting without introducing a hard dependency of plone.locking on other parts of Plone. (This does introduce a dependency of plone.app.controlpanel on plone.locking, but that seems less bad.) * plone.app.kss: - Fixed the broken implementation of the 'removeLockProtection' KSS action Summary of test assertions -- X default timeout is 10 minutes for TTW X site creation adds 'lock_on_ttw_edit' to site properties (value: True) X - (and migration) X plone.locking.lockable.TTWLockable has a refresh_lock method that updates the lock time X there is a configlet which can edit the lock_on_ttw_edit property Not tested yet but will be before merging: - the lock_on_ttw_edit property is actually taken into account by content (even if old locks remain from before the property was turned off) Tested manually (because I wasn't sure how to automate it): - The periodic AJAX call from unlockOnFormUnload.js actually updates the lock expiration time every five minutes. (This is easiest to test by changing the time to 5 seconds and watching the Firebug console.) - Locking, and the auto-refresh behavior, is correctly activated/deactivated when inline editing begins/ends. I only had time to test on Firefox and Safari, so if the reviewers can check other browsers I'd appreciate it. Needed documentation changes * Documentation of the locking feature should note the new setting in the site configlet for enabling/disabling locking. * Any existing documentation of lock timeouts should be adjusted to note the new behavior. Needed translations
Re: [Framework-Team] Concern about review progress
I was on vacation the past week and I will catch up and review in the coming days. Danny On 23 jan 2009, at 10:07, Wichert Akkerman wrote: We are not almost a week into the two review period, and at this point two out of the required 22 reviews have been done, two PLIPs have not been assigned a second reviewer and none of PLIPs have received UI feedback. That lack of progress has me a bit worried. Please do not make this a last-minute review rush! Wichert. -- Wichert Akkerman wich...@wiggy.netIt 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 mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Close Nominations Soon?
On 22 nov 2008, at 03:30, Raphael Ritz [EMAIL PROTECTED] wrote: Tom Lazar wrote: On 20.11.2008, at 09:47, Andreas Zeidler wrote: On Nov 19, 2008, at 6:29 PM, Steve McMahon wrote: It looks to me like we're getting a pretty good list of nominations. yes, very good! :) Shall we close nominations in a week? I can send deadline announcements to the lists and news. wasn't that the plan anyway, i.e. close it by the end of the month? anyway, +1 from me! +1 on both of the above from me ;-) +1 here as welk +1 for me too ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plone 4 framework team nomination
I want to nominate myself for the Plone 4 framework-team. My goal: protect Plone's UI or/and its future UI and make sure that technology doesn't drive the wrong UI concepts and choices. I have several years experience with Plone in this respect and I already fullfil this role as a framework-team member for Plone 3 and I'd like to continue this work. Especially now that we have rather radical and new plans for 4.0 so I want to make sure that we stick to state of the art, modern UI and interaction patterns. Danny Bloemendaal ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] 3.3 timeline
Sorry, wasn't online yesterday but for me this is a good idea. On 6 nov 2008, at 01:17, Andreas Zeidler wrote: danny, raphael, and also steve and jon, would that work for you? that's to say, realistically, like in being able to do all necessary reviews etc on time? :) if not, please tell us now so we can adjust things. we'd really like to stick with the plan this time... cheers, andi On Nov 5, 2008, at 1:36 PM, Wichert Akkerman wrote: The proposal we came up with today at lunch is: The PLIP implementation deadline will be half January, after which the framework team has a two week period to review all PLIPs. This will be followed by a week during which developers can rework their implementation (code, UI or documentation) to solve any problems found by the framework team. The framework team will then have another week during which is will re-evaluate previously rejected PLIPs. That means that half February we will have a final verdict for all PLIPs. In addition people are highly encourages to submit their implementation before the deadline, and the framework team will try to review PLIPs as soon as they are submitted. PLIPs submitted after the deadline will have to wait for 3.4. Steve and Jon will be asked to manage the process and make sure everyone is playing by the rules. Wichert. -- 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.6 released! -- http://plone.org/products/plone/ ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] 3.3 timeline
On 3 nov 2008, at 21:33, Tom Lazar wrote: On 03.11.2008, at 10:27, Wichert Akkerman wrote: I've been told the framework team wants to be involved with setting timeframes for releases. I want to propose to take this one step further during the PLIP handling phase: I would like the framework team to propose a timeline for PLIP implementation and review deadlines. Can the framework team make a proposal this week? perhaps, martijn, andi and myself (3/5ths of the team, afterall...) can jumpstart this with you over lunch day after tomorrow (after andi arrives here in tønsberg)? my idea is that the four of us could discuss a proposal which we then send to the list for approval. cheers, tom Excellent idea +1 ___ 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 29 okt 2008, at 10:05, Tom Lazar wrote: On Oct 28, 2008, at 10:20 PM, Danny Bloemendaal wrote: Well, I am all in favor of having the UI fixed. Perhaps some of the kss boys can do this. You need to have a hover event that shows a button next to the widget (button can styles using css into a pencil or something) and the click should trigger the edit mode. i may be wrong, of course, but i doubt anybody of the framework team would have voted for plip238 if we had such an implementation ;-) heck, if we had had a plip for the above scenario, that would have been voted in and wiggy probably would have never created #238. IOW: i'd rather disable a suboptimal implementation of a potentially cool feature (#238) than wait for an uncertain amount of time until we have a UI fix for that feature. I think that jeroen vloothuis could do this in an afternoon. we could ask him to help. please do! if he comes up with something, i'd like to propose that we treat his patch as an 'alternative implementation of #238', i.e. if we think of #238 as 'fixing inline editing' then jeroen's patch could still become part of plone 3.3 instead of sticking it into a new plip (which would then obviously have to wait until 3.4) just my $0.02, tom I talked to Jeroen and he believes it is not hard to do so I asked him to do it on top of this plip (http://plone.org/products/plone/roadmap/238 ). He is not garanteeing that it will be finished in time for 3.3 but we'll see. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Kicking off Plone 4: Release Manager candidate
On 26 okt 2008, at 22:42, Alexander Limi wrote: Hi team, There's been a lot of activity and excitement about Plone 4 after the Plone Conference, and I'd like for us to start moving on the development for it. Hanno Schlichting has said that he'd like to be the release manager for Plone 4, and I'd like to formally propose him as a candidate for this role. Martin Aspeli has indicated that he'd like to help Hanno in a developer communication role, so Hanno can focus on his job of the release manager, and Martin will help communicate what's going on to our core developers and add-on product developers. +1+1. Excellent idea. I'm sure that Hanno can do the job (and Martin of course). Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Plip 245?
Is it correct that http://plone.org/products/plone/roadmap/245 hasn't been officially proposed for 3.3? I can't remember we discussed it though. Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Notes from Framework Team Meeting in DC
Thank you Steve. I think this covers what I remembered as well. Good work. Danny On 20 okt 2008, at 00:20, Steve McMahon wrote: Here are my notes from the DC Framework Team meeting. Please discuss anything I've missed, gotten wrong, or stated too absolutely. We'll eventually codify the consensus version somewhere on Plone.Org. Thanks, Steve Mission -- The Framework Team is the gatekeeper for determining which Plone Improvement Proposals (PLIPS) are incorporated into particular versions of Plone. The team recruits release manager candidates and recommends them to the Plone Foundation Board. The team makes recommendations to the release manager for which PLIPS should be incorporated into Plone. Neither the team nor the release manager set the long-term vision for Plone. That is done by the Plone Community. The team is reponsible for taking community opinion and strategic goals into account when considering improvement proposals. The team has an obligation to account to the community for its decisions on Plone features. Framework Team Procedures --- Decisions on procedures and structure are to be made by consensus. The PLIP decision-making process should be transparent to the community. Recruiting discussions may be private. The Framework Team is self-perpetuating. It chooses members for itself and successor teams in consultation with team alumni. Criteria for choice may include a desire for diverse, in-depth experience, and the ability of candidates to work well in concert with existing and other proposed members. The number of members is flexible, and should ideally be odd. The team is not a formal committee of the Plone Foundation, but is expected to coordinate with the foundation board as necessary to achieve its mission. Recommendations to the release manager are made by voting on PLIPs. At least two team members should review every PLIP in depth. Ideally everyone should vote on every PLIP. The team may ask/appoint non-members to assist in secretarial, organizational and communication roles. Plone 3 and 4 --- We anticipate that Plone 3.x will be maintained and improved well into the development of Plone 4.x, and possibly after its release. The 3.x framework team will stay largely intact so long as feature improvements to 3.x are under consideration. The 3.x team will begin by end of month to recruit for a 4.x team. A call will be made to the community asking for applications. The 4.x team should be in place by January 30th, and one of its first acts should be to recommend a 4.x release manager to the board. Jon Stahl, Geir Bækholt, Steve McMahon and Matt Bowen have all volunteered to provide organizational, secretarial and communication assistance for the teams. -- Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] ATT1.txt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP 244: Portlet management improvements
On 16 okt 2008, at 17:35, Martin Aspeli wrote: - Create a site wide portlet category for portlets that should show on all pages (unless blocked). Then how do you unblock them? If I have such a global portlet and at some point a folder blocks the portlets and redefines them and in a subfolder you want to have that global portlet showing up again, how do you do that? Is it suddenly an addable portlet while it used to be a global portlet? 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. As wichert stated, this the argument here is that only the option to block all the portlets is actually causing the cumbersomeness here. For role-inheritance you see a similar thing but there the reason is security related and with a bit of though you will realize it is the only way to do it. I'm not convinced that you can't have a scheme of blocking portlet on an individual basis. Perhaps with a few UI tweaks this is easy to use. Like when you remove a portlet in the manager you will be asked to remove it everywhere (up that chain) or just here. - Improve the contextual manage portlets screen so that you can see what portlets will disappear/appear when you block/unblock. Sounds good. At least.. if you mean that you can see which portlets are there but blocked. (I'm currently working on a design for the sharing page that also does this properly). - Add a setting (actually, an annotation) to each individual portlet assignment that determines whether it is shown in subfolders or not. This will probably need to default to true, at least for migrated sites, but may be better off as defaulting to false. I'm not sure what the default would be. Initially I'd think default to True. Anyway, this setting lessens the need for a way to block individual portlets a little bit. It's not the same though. This will solve the problem of I want this portlet in this folder, but not all sub-folders. Currently, you need to go and block contextual portlets in each sub-folder, which is a pain. Each of these could be implemented separately, although they do go hand in hand. Cheers, 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP 244: Portlet management improvements
On 17 okt 2008, at 01:29, Jon Stahl wrote: One other thought to contribute to this topic: Right now, the system renders all placeful portlets, then all group portlets, then all type portlets. Grouping is bad. Especially if you allow some form or ordering. No user wants to be bound by an arbriary technical reason for grouping. If a user wants to have portlets in a mixed order, that is pretty much impossible. Perhaps we can add a simple weight value to each portlet, then order portlets by weight, regardless of whether they are place, group or type portlets? There are some UI considerations, and maybe this is too invasive. But we get it a fair amount. Weight? Why that? Why not allow them to be mixed as the user wants? Why that grouping at all? It's a technical reason not a usability reason. Just allow them to be mixed and you are done. I even would like to suggest to have the option to mix them on a user bases with drag and drop and store the order in cookies or something like that. We have that here in our intranet together with collapsible support and that works really well. But that's another topic ;-). Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP #243: Replace workflow history viewlet with content history viewlet
On 9 okt 2008, at 07:27, Wichert Akkerman wrote: I would like to propose PLIP 243 for Plone 3.3: Replace workflow history viewlet with content history viewlet. Motivation == The 'history' list in a document view does not show the full history of an object but only the workflow history. We are hiding versioning history information behind a (painfully ugly) history form. This can be confusing, and makes it harder to access versioning information. Proposal I propose two things: 1. instead of the workflow history viewlet use the content history viewlet that is already in plone.app.layout trunk. This viewlet mixes workflow and versioning information in a single overview and has convenient options to get more information about versioning changes. 2. remove the history content action and use the content history viewlet as a way to access the history information. Implementation == Most of the implementation is already done. Ask DannyB for a demonstration if you are at the conference or attending the UI sprint :) Wichert. Of course I'm for this. Here is an expanded history panel (see attachement): inline: Picture 7.png the ---^comparev- line allow you to see the diffs between what's above the line and the version below. The icons at the end are from left to right: Compare with current revision, Preview this revision, Revert to this revision. ___ 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
Re: [Framework-Team] Meeting up in DC
Is that on 808 7th St NW, Washington? http://maps.google.com/maps?f=qhl=engeocode=q=fado+pub,+Washington,+DC+20037ie=UTF8ll=38.900919,-77.021027spn=0.018269,0.043473z=15 And what time exactly? On 3 okt 2008, at 17:17, Steve McMahon wrote: Hi Framework Team, I asked our conference social planner, JoAnna Springsteen, for possibilities for a dinner spot where we could meet up Monday night and actually hear one another. Here are her suggestions. If one or more of these spots sound particularly good or bad, let me or the list know. Sometime in the next couple of days, I'll make an executive decision on our behalf. Steve Hmmm. Well Monday night we're going to go to Fado. It's a large pub that serves food. They're having a trivia quiz night and I'm trying to get a Team Plone together. If you guys ate there we could meet up with you later. Not sure if the food is great or if it's all that quite though. Science Club would be good but it's where we're going for our official pre-conf social Wednesday night, plus it has an all vegetarian menu which may not appeal to all. DC locals say Granville Moore's is supposed to be great both food and beer wise but it's not close to the metro. Sushi Taro would be good but you'd definitely have to make reservations to get in with that many people. Central is supposed to be great and it's near the conference location but it's a bit higher end and it's another place you'd have to make reservations. I liked the Brickskeller when we went there. It's a bit of a walk from the dupont circle metro but it has a huge beer menu and serves food. It's not a huge place but I could just see a group of geeks huddled in the corner here debating something. The locals aren't super impressed by it but I dug it. Again, you might want to check and see if they can accommodate a bigger group for dinner. I know the Capitol Lounge can handle big groups but I'm not sure that the food or atmosphere is a particular draw. The prices and food are both supposed to be decent so it probably won't wow you but it could be a safe bet for you to just walk in and get seated in a reasonable amount of time. -- Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] Meeting up in DC
sounds good.. what's this dinner meeting (or did I miss something)? On 6 okt 2008, at 11:36, Tom Lazar wrote: On Oct 6, 2008, at 9:26 AM, Steve McMahon wrote: I'll take that as a nomination for Fado. Fado it is! Shall we aim for 7pm? well, there's the dinner meeting at 6pm at the ethipian restaurant[1] and for 8pm at fados. my personal plan was to meet folks at 6pm at the restaurant (Meskerem 2434 18th St NW) and then head over to fados. so shall we say 8pm at fados? i'd like to go to both meetings... cheers, tom [1] http://www.openplans.org/projects/plone-conference-2008-dc/dinner-and-drinks My cell is +1 530.219.1431 On Mon, Oct 6, 2008 at 4:40 AM, Danny Bloemendaal [EMAIL PROTECTED] wrote: Is that on 808 7th St NW, Washington? http://maps.google.com/maps?f=qhl=engeocode=q=fado+pub,+Washington,+DC+20037ie=UTF8ll=38.900919,-77.021027spn=0.018269,0.043473z=15 And what time exactly? On 3 okt 2008, at 17:17, Steve McMahon wrote: Hi Framework Team, I asked our conference social planner, JoAnna Springsteen, for possibilities for a dinner spot where we could meet up Monday night and actually hear one another. Here are her suggestions. If one or more of these spots sound particularly good or bad, let me or the list know. Sometime in the next couple of days, I'll make an executive decision on our behalf. Steve Hmmm. Well Monday night we're going to go to Fado. It's a large pub that serves food. They're having a trivia quiz night and I'm trying to get a Team Plone together. If you guys ate there we could meet up with you later. Not sure if the food is great or if it's all that quite though. Science Club would be good but it's where we're going for our official pre-conf social Wednesday night, plus it has an all vegetarian menu which may not appeal to all. DC locals say Granville Moore's is supposed to be great both food and beer wise but it's not close to the metro. Sushi Taro would be good but you'd definitely have to make reservations to get in with that many people. Central is supposed to be great and it's near the conference location but it's a bit higher end and it's another place you'd have to make reservations. I liked the Brickskeller when we went there. It's a bit of a walk from the dupont circle metro but it has a huge beer menu and serves food. It's not a huge place but I could just see a group of geeks huddled in the corner here debating something. The locals aren't super impressed by it but I dug it. Again, you might want to check and see if they can accommodate a bigger group for dinner. I know the Capitol Lounge can handle big groups but I'm not sure that the food or atmosphere is a particular draw. The prices and food are both supposed to be decent so it probably won't wow you but it could be a safe bet for you to just walk in and get seated in a reasonable amount of time. -- Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team -- Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Framework Team Meeting at Conference
Can't we have a Page somewhere where everybody puts their info on? (hotel, arrival-departure, cellphone etc). I for instance arrive on sunday in the afternoon and it would be nice to know who is around at that time as well. :) Danny. On 11 sep 2008, at 18:38, Martijn Pieters wrote: On Thu, Sep 11, 2008 at 17:03, Steve McMahon [EMAIL PROTECTED] wrote: If everyone can indicate the neighborhood they're staying in (e.g., Du Pont Circle, near the conference center, etc), I'll look for a restaurant that's close to as many people as possible. I am staying at the Carlyle Suites Hotel, 1731 New Hampshire Ave NW, which makes it Du Pont Circle, I believe. -- Martijn Pieters ___ 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] Framework Team Meeting at Conference
Perhaps :) But maybe developers in general. Ah well, let's see when that page is comming. On 11 sep 2008, at 19:27, Steve McMahon wrote: There's a plan to do that for the conference in general. Would you like to have something particular to the framework team. It would be easy... On Thu, Sep 11, 2008 at 9:46 AM, Danny Bloemendaal [EMAIL PROTECTED] wrote: Can't we have a Page somewhere where everybody puts their info on? (hotel, arrival-departure, cellphone etc). I for instance arrive on sunday in the afternoon and it would be nice to know who is around at that time as well. :) Danny. On 11 sep 2008, at 18:38, Martijn Pieters wrote: On Thu, Sep 11, 2008 at 17:03, Steve McMahon [EMAIL PROTECTED] wrote: If everyone can indicate the neighborhood they're staying in (e.g., Du Pont Circle, near the conference center, etc), I'll look for a restaurant that's close to as many people as possible. I am staying at the Carlyle Suites Hotel, 1731 New Hampshire Ave NW, which makes it Du Pont Circle, I believe. -- Martijn Pieters ___ 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 -- Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Framework Team Meeting at Conference
I arrive on Sunday 5 and leave the next Sunday. On 4 sep 2008, at 22:33, Steve McMahon wrote: I'm not on the team, but will be happy to be scribe and facilitate in any other way that might be helpful. I'll be in DC Monday through Sunday. -- Steve McMahon Reid-McMahon, LLC [EMAIL PROTECTED] [EMAIL PROTECTED] ___ 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] Re: Framework Team Meeting in DC
I'm hoping to be there too. On 14 jul 2008, at 22:27, Martin Aspeli wrote: Alec Mitchell wrote: I'll be in D.C. and would attend the meeting on whichever day it may be held. I'll be there, Saturday to Monday. I'm giving a training course Monday and Tuesday, though. 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] availability over the next 5 months
I will be on vacation from 9-23 august. On 29 jun 2008, at 21:43, Wichert Akkerman wrote: Can the members of the framework team mail me some information on their availability for the next couple of months? If there are periods of a week or longer that you know you will not be able to dedicate enough time to framework team business I'ld like to know so I can take it into account when planning the next release(s). 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 mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: [Plone-developers] moving description to a viewlet
On 18 mei 2008, at 18:37, Martin Aspeli wrote: An object's description is intimately tied to its schema. A description renderer probably isn't a useful concept on its own. The decision on whether and how to render the description is part of the view logic of the object in question and should thus, IMHO, remain closely linked into the view template, not indirected away to a place where it's harder to manipulate. I just feel that the description is not part of the content. It is metadata: it describes what the object is about. As such it does not have business appearing in view templates, especially not in the way it does now. That is a mistake Plone made long ago, and something we should fix at some point. Yes, it was a bad choice to tie the description to the content back in the days. The problem started with placing the description widget at the top of the edit form while it should be at the bottom. After all, it is just before you save, you have to think of one or two sentences to describe WHAT the object is about for when people search for that item and see it in the listing. By placing it at the top, people always assume it is a lead in. Bad choice. Especially when people use it as a lead-in. Lead-ins are usually bad for search overviews. It hardly ever describes what the item is about. I think with a bit more discussion and input, we could arrive at this conclusion and consider a policy switch, but I think for 3.x the ship's sailed. For a lot of people, the way that Description is being used in views makes it a de-facto part of the content schema (rather than the metadata schema) and so something that users very much think of as a lead-in just as much as an abstract description for independent listings. We can't ignore that sunk assumption either. If people want a teaser or a lead-in, then the best way would be to add such a field. Then it's part of the content, can be placed on top of the edit form, just before the body (it's a lead-in after all). But I agree that the impact is maybe a bit too large. Danny Bloemendaal ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: tomorrow's PLIP review deadline
I have been reviewing last night but only posted my review in the review notes inside the plip. I was under the assumption that that was sufficient, sorry for that but I did review them. I'm now working on my last one #212. And to be honest, I didn't know that I had to vote for plips I didn't review myself. Does that make any sense? I fully acqknowledge the reviewers ability to make a good judgement for the plips. Danny On 19 feb 2008, at 02:36, Andreas Zeidler wrote: On Feb 18, 2008, at 12:50 AM, Andreas Zeidler wrote: oops, i only realized raphael had already looked at 212 in the middle of writing down that list. so actually it should have read #187 and #215 need to be reviewed for a second time, and #202 and #212 should probably also see another round of click-tests. afaik, neither tom nor danny have posted notes about their reviews of the above mentioned PLIPs. this does not only mean we've now missed the second deadline as well (even with the two extra days), but also prevents the team members from casting their votes on these PLIPs. imho, this really sucks! :( on top of this, i haven't seen any votes from danny and raphael (except on the PLIPs they've reviewed themselves), so i cannot send any recommendations to wichert, either. i'm effectively booked with fixed appointments for the rest of this week, so i won't be able to adjust my schedule again to accomodate these delays. one of you has to take over the job of going through the PLIP tickets (to check which still need attention), counting votes and passing on the team's recommendations to the release manager. i'll leave it up to you to decide who will have to do this, but perhaps it would make sense for wichert to nominate someone to avoid losing even more time... :( cheers, andi -- 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.0.6 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] My review status
On 18 feb 2008, at 01:28, Andreas Zeidler wrote: On Feb 16, 2008, at 8:52 PM, Danny Bloemendaal wrote: As you guys know I'm here to review plips when it requires UI attention. So I did 201 (and still working on that next week). As far as I can tell there aren't other plips that need that attention from me (please correct me if I'm wrong). well, i'd like to say that it was never really sort of officially communicated to me that your role in the team is just to stand by and give feedback when requested to. you've said initially that you couldn't say much about technical details, which is fair, but imho that doesn't really exclude you from doing other review tasks. like raphael said in one of his posts, most of the time looking at code alone isn't all that matters. Ok, I'm sorry if that wasn't communicated better or maybe it was my misunderstanding. Point is that back in the days, Wichert asked me if I wanted to join the team as a UI designer/tester to make sure that we could keep the standard high regarding usability. I said that I would like to do that but that people shouldn't expect from me that I would participate heavily in 'true' framework discussions. That wasn't a problem so I volunteered. But.. you may be right that I still could be of more help than what I did so far. so when you said you were gonna review things after that week you were unavailable, i.e. starting from february 11th, i was indeed expecting you to do as many reviews as everybody else. these could or rather should have included click-tests as well as some thinking about corner-cases and trying to break things etc. until wichert updated the schedule (yesterday, i.e. sunday) the review deadline was on saturday. until then you've only commented on two plips afaik, but should have on at least seven (as posted several times)... :( So, yes, I could certainly do click-tests. Maybe my reluctance so far was because if me not being able to foresee in which plips I can be of any help regarding this. So, I guess that's my status. hmm, that kinda sounds like you didn't think the above also applied to you. i wonder what went wrong here. at the very best, we've had some pretty severe miscommunication here. quite frankly, hardly replying to any mails and most importantly not making this point of view very clear when seeing several posts with obviously wrong numbers in terms of review per team member is not acceptable to me. You are right here I'm affraid. I'll try to do better in the near future :( that said and considering the current status of the reviews, i'm gonna ask you to please do secondary reviews on 202 (formlib inline validation / editing), 212 (jquery) and — most importantly — 215 (kss update) tomorrow. there's no need to look at any code, but the review should include manual click-tests for more or less all affected / replaced js functionality in plone. Ok, I will do that today and again, sorry for the miscommunication. cheers, andi -- 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.0.5 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] Suggestion for more a better streamlined process?
Hi folks, I have been thinking (yes, I try that occasionally) and I must say that we really need some sort of better tooling for the entire review process. It is all too scattered if you ask me. I really don't know where I have to find what I need to know for reviewing. Plone.org, track, svn, plone-devevelopers@, framework-team@ etc etc, I need one place where I can find everything there is to know: * which releases are there and * which plips do we have to review for this release * which deadlines are there * who are the reviewers (ok, not so necessary but for completeness...) * discussion threads for each plip during the review in ONE PLACE * status overview of the review process * instructions per plip on how to checkout, review, what to look for etc * It may sound like 'cursing in the church' (pardon my dutch) but many of the modern forum tools out there already allow you to do all this. You could set it up where each release is a forum with some sticky posts listing the plips with urls to the plip definition and threads for each plip in the release. Then each plip can have it's own discussion. We could add a few sticky posts with process status and other information needed for each release and each plip. Given the low amount of plips per release I think that a forum isn't so bad. The problem with Trac is that you always have to do queries to get to the data you need and you never know if you haven't missed anything. I always have a feeling of drowning in Trac-like tools. It may seem strange to suggest this but at least we don't have to re- invent something ourselves. It's easy to set up and I even think that ploneboard should support this from the start. I certainly would volunteer (with some help) to set up such a board or... when people have even better ideas, to help implement that. In any way, we have to improve on this and I really don't think it is hard to do :)) Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: comments on plip187: WebDAV
On 18 feb 2008, at 15:42, Sidnei da Silva wrote: We could either: - Display the 'contents' of a 'smart folder' and allow for downloading them. The problem might be that since they are not directly contained inside that 'smart folder', maybe some WebDAV clients will complain that the URLs for those items are not 'contained in' the parent. - Serialize the criteria for the 'smart folder', and display it as non-folderish. that seems to make most sense to me at the moment That == ? Can't you expose smart folders as read only folders? So you can drag things out of it but nothing into it? That is what I would expect. In fact, if I make a smart folder in Mac OS Finder, afaik I can not add anything to it but I can drag files out of it. Another issue is, when you upload a file to a 'smart folder', where should this file end up? I'm not sure we should even try this. Why not? My suggestion solves that part :) Danny Bloemendaal. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] My review status
As you guys know I'm here to review plips when it requires UI attention. So I did 201 (and still working on that next week). As far as I can tell there aren't other plips that need that attention from me (please correct me if I'm wrong). So, I guess that's my status. Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] My conclusion regarding 201 (USW)
Today Florian made some changes to überselectionwidget to use the same pattern as Mac OS Finder's column view and it rocks and I really think that this is the way how it should work. Add search, good mouse/ keyboard navigation, object details etc to it and you have a very powerful and easy to use widget. However, it needs a bit more designing, twaeking and getting it just right (tm) so I think that that will not make it into 3.1 but surely 3.2. Florian thinks that it can put some parts of this plip in 3.1 though so that it is even better that was is now in 3.0 (backend, js and js-less search) so I think that that part could land in 3.1. Next week I will work with Florian on some more designs, mockups and specs. So.. stay tuned :) Oh, when this widget is going to work as planned.. we could use that same pattern for navigating the portal as an alternative to the navtree ;-). Now.. that would be interesting to explore as well someday. It is so fast... Ah well.../me is dreaming away. (which reminds me... Wichert have you added my kss stuff for expandable/ collapsible navtree folders?.. ok ok.. that's off topic.. let's not discuss it here ;-)) but oh my do I love that in our intranet.. don't want to miss that navtree feature anymore). Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Organizing the review
On 19 jan 2008, at 11:29, Tom Lazar wrote: andi, sorry about the silence, i've fallen a bit ill (that noro virus that's going round here in berlin, watch out...) i think the idea with trac is excellent and have, in fact, been harbouring similar ideas in that regard but kept quiet since i knew that i don't have the resources right now to do something about. it would be great, if you could set up a trac instance to get us up and running. thanks, tom +1 On Jan 18, 2008, at 3:53 PM, Andreas Zeidler wrote: On Jan 16, 2008, at 12:20 PM, Andreas Zeidler wrote: so, how about (ab)using trac tickets to assign plips to team members and collect review notes etc? that way people could be cc'ed to make sure the author(s) and relevant team members get the news. plus using an additional query it would be easy to see what's already done/assigned/pending etc... what do you think? hmm, not too much it would seem... :) does anyone have a better suggestion on how to coordinate the review? if not (and if nobody objects) i'll go ahead an create those review tickets some time during the weekend... cheers, andi -- 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.0.5 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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Suggestion for adding Usecase information
On 24 dec 2007, at 04:27, Hanno Schlichting wrote: Danny Bloemendaal wrote: After having waded through a big pile of plips I often (as a less technical oriented member) had problems determining what the actual usecase was that it was trying to solve. I would like to suggest (when thechcnically possible) to add such a section in a plip. I'd like to see a real-world usecase example (for the less technical ppl) what the plip has to solve/support/whatever. Something like: Suppose someone wants to write a product that supports this or that. Right now he has to do this or that to do this but with this plip in place he only has to do such or so. Right now, the Motivation section isn't exactly that. In most cases, the author immediately dives into technical details. I think it would help to have this addition? Or am I talking nonsense here? +1, I think we have been bad both on the side of use-case centric and integrator targeted information. So what is needed? I think that only an extra header in the boilerplate text for a plip would be enough (and stress that writes fill it in of course). ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Suggestion for adding Usecase information
On 24 dec 2007, at 11:24, Martin Aspeli wrote: Danny Bloemendaal wrote: On 24 dec 2007, at 04:27, Hanno Schlichting wrote: Danny Bloemendaal wrote: After having waded through a big pile of plips I often (as a less technical oriented member) had problems determining what the actual usecase was that it was trying to solve. I would like to suggest (when thechcnically possible) to add such a section in a plip. I'd like to see a real-world usecase example (for the less technical ppl) what the plip has to solve/support/whatever. Something like: Suppose someone wants to write a product that supports this or that. Right now he has to do this or that to do this but with this plip in place he only has to do such or so. Right now, the Motivation section isn't exactly that. In most cases, the author immediately dives into technical details. I think it would help to have this addition? Or am I talking nonsense here? +1, I think we have been bad both on the side of use-case centric and integrator targeted information. So what is needed? I think that only an extra header in the boilerplate text for a plip would be enough (and stress that writes fill it in of course). I think this fits well inside the Motivation box we already have. What's needed is a framework team that proactively asks people to fill in that information when submitting PLIPs, should it be insufficient. I don't agree entirely. Motivation doesn't have to b a description for the usecase. Motivation is very general and can be a technical story only. A usecase is a 'normal'-people's description of what it tries to solve. It's almost like a scenario or a scriptive way to describe things. Motivation ís being used right now but hardly ever in the scenario/use-case kinda way. I don't think it is good idea to 'correct' people if they didn't use Motivation is this way. It's better to have them write it from the start. Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] PLIP184 - additional portlets
On 23 dec 2007, at 01:31, Martin Aspeli wrote: Hi guys, PLIP 184 is about adding new portlets. I've got two covered and mostly complete: - plone.portlet.static[1] provides static text with a Kupu widget - plone.portlet.collection[2] provides a listing based on a collection Is it an idea that this collection portlet has some kind of next/ previous functionality that uses kss and ajax to get the next batch inside the portlet? With kss this is almost trivial and it enhances the UX of the thing. Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Suggestion for adding Usecase information
After having waded through a big pile of plips I often (as a less technical oriented member) had problems determining what the actual usecase was that it was trying to solve. I would like to suggest (when thechcnically possible) to add such a section in a plip. I'd like to see a real-world usecase example (for the less technical ppl) what the plip has to solve/support/whatever. Something like: Suppose someone wants to write a product that supports this or that. Right now he has to do this or that to do this but with this plip in place he only has to do such or so. Right now, the Motivation section isn't exactly that. In most cases, the author immediately dives into technical details. I think it would help to have this addition? Or am I talking nonsense here? Cheers Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Kupu PLIP for 3.1
On 15 dec 2007, at 23:24, Danny Bloemendaal wrote: On 15 dec 2007, at 21:25, Alexander Limi wrote: Hi guys, Just a quick email to say that I have been traveling (and without internet connection :( ) since before the PLIP deadline. The one I want in 3.1 isn't really a core thing as such — it's in Kupu — but I think it should have a PLIP to make it follow the process anyway. It's detailed in this issue: http://dev.plone.org/plone/ticket/6882 (Duncan has already made Kupu work with the latest Webkit/Safari builds, so half the PLIP is already done) Well, that's a bit too quick. I have been using kupu with webkit lately and I can't say that it is production ready. Either kupu or webkit does strange things with selections like inserting weird spans with strange webkit classnames. Which forces you to switch to html view quite often. It needs some more thorough testing. So it's not done yet (but almost there). Yesterday Duncan and I spend the afternoon experimenting with kupu and webkit (together with some webkit developers) and we reported a few problems that right now make it almost impossible to use kupu with webkit. There's still a lot of work that has to be done, mostly on the part of webkit. So the only thing that we can do now is to write tests and submit bugs in webkit's tracker. But the guys at webkit so far have shown interest in the matter. So.. to be continued... ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: preliminary results for PLIP selection call for votes!
Sorry for the delay guys. I commented on all the plips. On 22 dec 2007, at 12:22, Andreas Zeidler wrote: hi all, On Dec 22, 2007, at 12:37 AM, Andreas Zeidler wrote: ps: i still got 4 votes to cast, but have to go offline, since i'm occupying a room in which people want to go to sleep now... sorry about that — i'll post my votes and do the bookkeeping in the morning. here's a first summary of all votes cast so far by the framework team on selection particular plips for inclusion into plone 3.1: * submitted plips (see http://plone.org/products/plone/releases/3.1) : 26 * votes expected: 5 x 26 = 130 * submitted votes: 98 of 130 = 75.4% (only counting votes cast on the plip pages) as it looks danny has only casted a few votes through the mailing list, but not updated the corresponding plip pages yet. also, they're far from complete, afaik. so danny, could you please asap either go through the list of plips and add your votes or alternatively post a list of all your votes here? not counting danny's votes we're at 94.2% with 6 missing votes. for your convenience, these are: * Tom on #187, #195, #218, #219, #221 * Rapahel on #187 please also try to cast those asap. that said, how long do we want to wait for those missing votes and do we have a plan on how to proceed if they don't arrive? i'd suggest waiting until midnight tonight at most, i.e. one day, and then accept/reject plips by majority vote. thoughts? for the time being i think it should be pretty safe for plip authors to judge if their plips will be accepted for 3.1 from the current standings — at least for the big majority of plips. these are: #184: +4 (4 votes) #187: +0 (2 votes) #195: +3 (3 votes) #196: +4 (4 votes) #199: -4 (4 votes) #200: +4 (4 votes) #201: +3 (4 votes incl 1 abstained) #202: +4 (4 votes) #203: +4 (4 votes) #204: +4 (4 votes) #205: +4 (4 votes) #207: +4 (4 votes) #208: +4 (4 votes) #209: +4 (4 votes) #210: +4 (4 votes) #211: +4 (4 votes) #212: +3 (4 votes incl 1 abstained) #213: +4 (4 votes) #214: -4 (4 votes) #215: +4 (4 votes) #216: +4 (4 votes) #217: +4 (4 votes) #218: +3 (3 votes) #219: -1 (3 votes) #220: +4 (4 votes) #221: +0 (3 votes) attached you'll find a compilation of all votes for reference. cheers, andi votes.txt -- 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.0.4 released! -- http://plone.org/products/plone ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: PLIP: Template overrides
I tot On 14 dec 2007, at 18:52, Alec Mitchell wrote: On Dec 14, 2007 7:56 AM, Malthe Borch [EMAIL PROTECTED] wrote: so, while i also like the idea, i'm not too sure if plone should ship with it. i'd agree with martin we should discuss and think this through a little further. nevertheless, i don't see why the plip wouldn't be acceptable, so +1 on that. True. I say, let's think of z3c.jbot as inspiration and then accept the PLIP that we need some easy way of customizing the default plone skin. I'd like to see some more detail on this PLIP. Currently, it seems to assume the reader is familiar with z3c.jbot, or requires the reviewer to exaimine the jbot code/docs (which is an burden better left for the code review phase). Of course my opinion is irrelevant. Also, I'm very much in favor of easier template customization, provided it's still relatively easy to figure out where a particular template/view is coming from. Alec I totally agree with Alec here. Since my acquired middle name these days is Customize, i'm very curious about what this plip means. Could someone elaborate a bit on this please? Danny Customize Bloemendaal ___ 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 219: New site search implementation
On 14 dec 2007, at 21:10, Wichert Akkerman wrote: I want to propose PLIP 219: New site search implementation http://plone.org/products/plone/roadmap/219 Since I discussed this with Wichert together with Cornelis in depth I'm all for it. It will greatly improve search results for a UI perspective. See how apple.com deals with live search. It's excellent. +1 Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Two more PLIPs
On 13 dec 2007, at 08:41, Raphael Ritz wrote: Tom Lazar wrote: On 11.12.2007, at 13:35, Laurence Rowe wrote: I'd like to see the following for 3.1: #210: Improve UI support for objects on multiple workflows DCWorkflow allows for a chain of workflows to be specified for a type. please explain. does chaining mean, that an object/type can have multiple workflows associated sequentially? or does each given state have the sum of all of the workflows transitions available? More the latter than the former. Objects can be subject to several workflows at once. This implies multiple state variables of course. Indeed you get a sum of all possible transitions offered. I used to use this feature to provide locking functionality before Plone itself did it (but in a different way now). If you want to see an example in action check out my LockingWorkflow product in a Plone 2.5 site. And to drive home the point here: the CMF workflow tool and DCWorkflow have supported this from the onset. It is only Plone's UI that's kind of hiding this from you. and BTW: +1 from me on the issue I truely think that this isn't as trivial as it may seem. Is it only a UI issue? I know plone relies on several locations for the review_state attribute. What if an object has several states (which is possible if you have multiple workflows assigned)? Aren't there configlets that allow you to do things with this attribute like the navtree? What about worklists? I think that when we agree that an object can have more than one states, we have to support it everywhere in a concise way. I want to see a list of all the locations and situations where this may be an issue. Is the code truely multiple- state/transition aware? It's not only changing content_status_modify in my opinion. The state change drop-down should also show that there are more workflows and perhaps group the transitions per-state. So, my point is: we either do it right or we don't do it at all :) And for now: +0 Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Two more PLIPs
On 13 dec 2007, at 12:51, Laurence Rowe wrote: Danny Bloemendaal wrote: I truely think that this isn't as trivial as it may seem. Is it only a UI issue? I know plone relies on several locations for the review_state attribute. What if an object has several states (which is possible if you have multiple workflows assigned)? Aren't there configlets that allow you to do things with this attribute like the navtree? What about worklists? I think that when we agree that an object can have more than one states, we have to support it everywhere in a concise way. I want to see a list of all the locations and situations where this may be an issue. Is the code truely multiple-state/transition aware? It's not only changing content_status_modify in my opinion. The state change drop-down should also show that there are more workflows and perhaps group the transitions per-state. So, my point is: we either do it right or we don't do it at all :) And for now: +0 Danny. We already do it, just not very well ;-) In 3.0 it works so long as you keep your transition ids unique across workflows. Catalogued workflow variables are calculated so that the first in the chain takes precedence, so nothing breaks here. Are worklists still used in Plone? They are a per workflow feature of DCWorkflow anyway, so are not affected. I don't think so. But I more mean things like portlets, various interfaces where you can pick a wf-state etc. You don't want to not show-up a set of wf-states in one location while in other places you can see them. Workflow actions are already grouped as the actions are calculated sequentially from workflows. It would be nice to have a separator and a workflow title shown too, but I'm not sure what this should look like UI wise. How about this? --- Workflow 1 Submit Approve --- Workflow 2 Confirm Reject --- Advanced... Something like that or perhaps another expand level in the menus. Also, something that came to my mind is that the workflow configlet has to be aware of this as well. I'm not sure what the problems may be but it allows you to reassign new states to objects if you switch to another workflow. Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] My PLIPs for 3.1
On 12 dec 2007, at 00:03, Encolpe Degoute wrote: I'd like to see the following for 3.1: #214: Merge of CMFPlacefulWorkflow into CMFPlone/WorkflowTool CMFPlacefulWorkflow is now mature enough to be merge into the workflow tool: * since two major version there's no critical bug on it * GenericSetup support is implemented in the trunk * let him outside the workflow tool would leave 2 more monkey patches in Plone bundle * all page templates can be merged into a plone_workflow skin with the #210 Ok, how shall I say this? ;-) First of all, I truely like the idea of placeful workflows. The idea is good and I had a need for that in several occasions in the past. However, back in the days when it was introduced in plone I experimented with it and to be honest, the UI was a horrible mess. I understood the concept but the UI made me scream. And from what I've heard and seen afterwards, it hasn't become any better. That's why we (me,limi and others) decided to not have it installed by default to begin with. So, before I would say +1 I think that this beast needs a true overhaul for the UI. Workflow as it is is already hard to understand for many (end)users (mostly because it is not really a 'flow' (at least for users) but more a state-engine, but that's another discussion, and because it is being misused as a permissions managing system) and introducing placeful wfs makes it even harder. So, unless we fix this, I give this a -2. And it is far from trivial to do this right. Configlets need to be aware and redesigned. Containers need to have proper UI where you can assign (overrule) workflow(s!! see the other plip) in that place. And it doesn't end here. What about reassinging wfs? What happens with objects that have states that only exist in that workflow in that context? Are they reset to other states? Do you have to reassign new states as you can right now in the wf-configlet that we designed in Norway two years ago? What happens if you move an object to another folder where there's another workflow active. What happens with the permissions? How does it behave with multiple-workflows (see the other plip discussion)? How does it play with the current wf-confliget? As you can see, a lot of issues need to be addressed properly. And it is really a challenge to do this right. Especially because we introduce multiple-object workflows as well. Danny. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Stick to this list
Hi folks, Just a small request: can we stick to this list for all framework communications? Prevents a lot of double emails ;-) Danny ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
