From hanno at hannosch.eu Mon Jan 4 19:42:15 2010 From: hanno at hannosch.eu (Hanno Schlichting) Date: Mon Jan 4 19:42:45 2010 Subject: [Framework-Team] Plone 4 - holidays are over :) Message-ID: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> Heya. Some of us have been busy over the holiday season and worked a bit more on Plone 4. The next question now is: What is missing for a beta release? I'll allow myself to give my opinion on that. Eric feel free to disagree, it's your call :) In general I think Plone 4 is in good overall shape. But there's some blockers and critical issues noted in the bug tracker, which we need to address. I cleaned up Trac, so the 4.0 milestone only has tickets which are new to Plone 4.0 and should *all* be resolved before a release candidate. But here's the list of things that we need to tackle, before we can label a release "beta" in my opinion: Unified folders #9912, #9791 This comes down to: What to do with the "Large Plone Folder" during upgrades. To actually unify folders, we need to migrate all existing large folders to the new unified type. From what I understand that type should have an option in its schema, that allows to turn on/off the orderability. When migrating large folders, orderability should be turned off. Currently the large folders are left as is and we don't have such an option in the schema. TinyMCE vs. Kupu #9945, #9783, #9877, #9949, #9956, #9976, #9637, #9958 Overall we always have many issues with our visual editor. Kupu is far from being problem-free, so we cannot expect TinyMCE to suddenly be all perfect. So I wouldn't call all of the listed tickets critical. But one really critical problems is, that TinyMCE doesn't work well enough in Safari/Chrome to give it to normal users. The proposed solution is to install both Kupu and TinyMCE by default and force Kupu for all Safari/Chrome users. Kupu has such a browser detection logic, as it also didn't work with Safari for a long time. It did a fallback on a plain textarea, but we can do better today having two editors with different browser coverage. Sunburst (or themes in general) There's quite a number of open tickets in the Templates/CSS component. For some parts of the UI, there's currently no styling information. While we can fix some of those during the beta cycle, I think we should fix everything that requires changes to main_template or needs new viewlet managers and the like before a beta release. Noteworthy are #9278, #9995 and #8805 (don't ship with NuPlone anymore). JS dialogs #9805, #9806, #9921, #9693, #9957, #9964, #9977 All of these essentially mean that an operation done in a pop-up doesn't redirect and reload a new page. So any kind of feedback (positive, reconfirmation and failures) is lost. The other problem is that the original page (shown in the background of the dialog) might show information that is changing as a result of the dialog action. For example publishing an object in a dialog, needs to refresh the page, as its workflow state needs to be reflected, the item might now show up in the navigation tree, a calendar or any other type of portlet. It's a bit sad to see these problems, as we have already encountered all of them, when first applying AJAX/KSS in the early Plone 3 stages. We ended up reverting to a non-AJAX UI for most things, as almost all of our UI actions can have arbitrary effects. I'm afraid that we need to re-evaluate all actions that use the new dialogs and discuss them. We haven't had a PLIP review of the individual dialogs. I think we have missed to pass on the hard earned knowledge learned from the early Plone 3.0 days, but luckily it's not too late. User / Group handling #9789, #9966, #5548, #9743, #9898, #9777, #9710, #9732, #9955, #9960, #9742, #9748 There's a ton of problems with the various new user and groups templates and related password handling functionality. If we want to claim that we improved anything in this regard (as our PLIP's claim) we need to fix this stuff. Not all of this needs to be fixed before a beta, but we need to get some good progress on these or they'll never be done. Otherwise we have some issues related to the installers. I just refactored a large part of the zope2instance recipe, which might have broken things in the installers. I didn't test the new changes on Windows yet, so the current recipe trunk quite definitely some issues. I'll fix these during this week. Finally there is one open PLIP (https://dev.plone.org/plone/ticket/9314) about the "Developer Pack" for the installers. I have no idea what the status on this one is. Personally I disagree with some of the choices mentioned in the PLIP (like shipping the unmaintained Clouseau, using eggtractor where buildout covers the same use-case today, turning on debug-mode in zope.conf, which should only be done via bin/instance fg vs. bin/instance console). It would be good to get an idea what the current status of this is and how it is implemented. Looking at this there's still a ton to do. I'll leave it to Eric to figure out whom to "encourage" to get these things done ;-) Hanno From ems174 at psu.edu Tue Jan 5 02:36:02 2010 From: ems174 at psu.edu (Eric Steele) Date: Tue Jan 5 02:36:14 2010 Subject: [Framework-Team] Plone 4 - holidays are over :) In-Reply-To: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> Message-ID: On Jan 4, 2010, at 2:42 PM, Hanno Schlichting wrote: > Heya. > > Some of us have been busy over the holiday season and worked a bit > more on Plone 4. The next question now is: > > What is missing for a beta release? > > I'll allow myself to give my opinion on that. Eric feel free to > disagree, it's your call :) > > In general I think Plone 4 is in good overall shape. But there's some > blockers and critical issues noted in the bug tracker, which we need > to address. I cleaned up Trac, so the 4.0 milestone only has tickets > which are new to Plone 4.0 and should *all* be resolved before a > release candidate. But here's the list of things that we need to > tackle, before we can label a release "beta" in my opinion: > ...big snip... > Looking at this there's still a ton to do. I'll leave it to Eric to > figure out whom to "encourage" to get these things done ;-) > > Hanno > Thanks Hanno. I've been slogging through the changelogs trying to get caught up on what's been done over the last two weeks. Between whatever plague it was that I contracted in late December and the holidays, I've been mostly useless lately. We're definitely close. I'd love to see a beta out by the 18th. I'll start rounding up people to get the worst of it cleaned up. There's a lot above to address, so I'll just make a few points: 1) I've got people (including myself) on most of the user/groups stuff. Some of that needs to be aired out here, which I'll do tomorrow. 2) We *really* need to move away from this whole "limi's theme" thing where Alex is the point-of-failure for anything template/design related. These are the most visible and obvious bugs and though they're not necessarily the most critical, they're the ones that leave the biggest impression of our "doneness". Denys has been picking up some the slack, but I'd like to find 1-3 more people willing to have at it. 3) /me clears his throat in witsch's general direction ;) 4) I'll talk with Steve about the JS issues. He's got quite a lot of tickets assigned at the moment, so I'm guessing he could use some help. Just a cursory look at the problem leads me to think there's a generally easy way of fixing it across the board, but also a nicer, one-less-page-load way that would be much more involved. And on points 2 and 4...what does the UI team do these days, do we still have one? Oh, and you said... > Personally I disagree with some of the choices mentioned in the PLIP > (like shipping the unmaintained Clouseau, using eggtractor where > buildout covers the same use-case today, turning on debug-mode in > zope.conf, which should only be done via bin/instance fg vs. > bin/instance console) A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. Eric From optilude+lists at gmail.com Tue Jan 5 02:56:29 2010 From: optilude+lists at gmail.com (Martin Aspeli) Date: Tue Jan 5 02:57:02 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) In-Reply-To: References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> Message-ID: <4B42AA5D.3020404@gmail.com> Eric Steele wrote: >> Personally I disagree with some of the choices mentioned in the PLIP >> (like shipping the unmaintained Clouseau, using eggtractor where >> buildout covers the same use-case today, turning on debug-mode in >> zope.conf, which should only be done via bin/instance fg vs. >> bin/instance console) > > A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. You mean that wasn't a typo? /me is astonished. :) Since when have we had that? Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book From hanno at hannosch.eu Tue Jan 5 04:48:52 2010 From: hanno at hannosch.eu (Hanno Schlichting) Date: Tue Jan 5 04:54:54 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) In-Reply-To: <4B42AA5D.3020404@gmail.com> References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <4B42AA5D.3020404@gmail.com> Message-ID: <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> > A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. Eh, how do you guys start an instance without the forced debug mode of "fg"? You don't use "start" for that, do you? > Since when have we had that? Since we use buildout or to be more precise, April 2008. Let me quote the PyPi page: 1.8 (2008-04-05) Added console command to the instance script, which is equivalent to fg but does not implicitly turn on debug mode but respects the zope.conf setting. [hannosch] One month later we changed it not to fork a process internally, so this is what we've been using for supervisord configurations for years. Hanno From optilude+lists at gmail.com Tue Jan 5 04:59:06 2010 From: optilude+lists at gmail.com (Martin Aspeli) Date: Tue Jan 5 04:59:38 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) In-Reply-To: <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <4B42AA5D.3020404@gmail.com> <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> Message-ID: Hanno Schlichting wrote: >> A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. > > Eh, how do you guys start an instance without the forced debug mode of > "fg"? You don't use "start" for that, do you? I guess I never do that. :) >> Since when have we had that? > > Since we use buildout or to be more precise, April 2008. Let me quote > the PyPi page: > > 1.8 (2008-04-05) > > Added console command to the instance script, which is equivalent to > fg but does not implicitly turn on debug mode but respects the > zope.conf setting. [hannosch] > > One month later we changed it not to fork a process internally, so > this is what we've been using for supervisord configurations for > years. Heh, good. :) I've been using a lower level script (run.py or something, deep inside Zope) in supervisord that I guess does the same thing. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book From davidglick at groundwire.org Tue Jan 5 04:59:34 2010 From: davidglick at groundwire.org (David Glick) Date: Tue Jan 5 05:00:13 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) In-Reply-To: <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <4B42AA5D.3020404@gmail.com> <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> Message-ID: <4B42C736.9030003@groundwire.org> Hanno Schlichting wrote: >> A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. >> > > Eh, how do you guys start an instance without the forced debug mode of > "fg"? You don't use "start" for that, do you? > Now you know why we were annoyed by not having a way to opt out of the resource registries debug mode matching Zope's :-p >> Since when have we had that? >> > Since we use buildout or to be more precise, April 2008. Let me quote > the PyPi page: > > 1.8 (2008-04-05) > > Added console command to the instance script, which is equivalent to > fg but does not implicitly turn on debug mode but respects the > zope.conf setting. [hannosch] > > One month later we changed it not to fork a process internally, so > this is what we've been using for supervisord configurations for > years. > Man, I even vaguely remember seeing that changelog entry go by, but completely forgot about it. We've been using parts/instance/bin/runzope with supervisord; this is better. David -- David Glick Web Developer Groundwire 206.286.1235x32 davidglick@groundwire.org http://groundwire.org ONE/Northwest is now Groundwire! From davidglick at groundwire.org Tue Jan 5 05:00:27 2010 From: davidglick at groundwire.org (David Glick) Date: Tue Jan 5 05:00:58 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) In-Reply-To: <4B42C736.9030003@groundwire.org> References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <4B42AA5D.3020404@gmail.com> <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> <4B42C736.9030003@groundwire.org> Message-ID: <4B42C76B.6090104@groundwire.org> David Glick wrote: > Man, I even vaguely remember seeing that changelog entry go by, but > completely forgot about it. We've been using > parts/instance/bin/runzope with supervisord; this is better. > David I worded that ambiguously. I meant that using bin/instance console is better. David -- David Glick Web Developer Groundwire 206.286.1235x32 davidglick@groundwire.org http://groundwire.org ONE/Northwest is now Groundwire! From aclark at aclark.net Wed Jan 6 05:57:59 2010 From: aclark at aclark.net (Alex Clark) Date: Wed Jan 6 05:58:31 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <4B42AA5D.3020404@gmail.com> <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> Message-ID: On 2010-01-05, Martin Aspeli wrote: > Hanno Schlichting wrote: >>> A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. >> >> Eh, how do you guys start an instance without the forced debug mode of >> "fg"? You don't use "start" for that, do you? > > I guess I never do that. :) > >>> Since when have we had that? >> >> Since we use buildout or to be more precise, April 2008. Let me quote >> the PyPi page: >> >> 1.8 (2008-04-05) >> >> Added console command to the instance script, which is equivalent to >> fg but does not implicitly turn on debug mode but respects the >> zope.conf setting. [hannosch] >> >> One month later we changed it not to fork a process internally, so >> this is what we've been using for supervisord configurations for >> years. > > Heh, good. :) I've been using a lower level script (run.py or something, > deep inside Zope) in supervisord that I guess does the same thing. So are they the same or not? If so, then we can stop feeling like idiots for missing 'bin/instance console' and continuing to use runzope ;-) I'm getting the impression 'bin/instance console' is just a convenience. > Martin > From dukebody at gmail.com Wed Jan 6 12:02:20 2010 From: dukebody at gmail.com (=?UTF-8?B?SXNyYWVsIFNhZXRhIFDDqXJleg==?=) Date: Wed Jan 6 12:10:15 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) In-Reply-To: <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <4B42AA5D.3020404@gmail.com> <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> Message-ID: Hanno Schlichting wrote: > 1.8 (2008-04-05) > > Added console command to the instance script, which is equivalent to > fg but does not implicitly turn on debug mode but respects the > zope.conf setting. [hannosch] > > One month later we changed it not to fork a process internally, so > this is what we've been using for supervisord configurations for > years. I've updated http://plone.org/documentation/manual/developer-manual/managing-projects-with-buildout/creating-a-buildout-for-your-project to reflect the availability of this command: """ Running: bin/instance console is equivalent to bin/instance fg, but does not implicitly turn on debug mode but respects the debug-mode setting in buildout.cfg. This can be useful to run Zope in non-development mode with daemon-control programs like supervisord. """ I hope it's ok. :) -- israel From l at lrowe.co.uk Wed Jan 6 12:52:02 2010 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed Jan 6 12:52:29 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) In-Reply-To: References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <4B42AA5D.3020404@gmail.com> <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> Message-ID: 2010/1/6 Alex Clark : > On 2010-01-05, Martin Aspeli wrote: >> Hanno Schlichting wrote: >>>> A quick poll in #plone-framework showed that myself and Messrs. Glick and Clark had never heard of bin/instance console. We need to document the crap out of that. >>> >>> Eh, how do you guys start an instance without the forced debug mode of >>> "fg"? You don't use "start" for that, do you? >> >> I guess I never do that. :) >> >>>> Since when have we had that? >>> >>> Since we use buildout or to be more precise, April 2008. Let me quote >>> the PyPi page: >>> >>> 1.8 (2008-04-05) >>> >>> Added console command to the instance script, which is equivalent to >>> fg but does not implicitly turn on debug mode but respects the >>> zope.conf setting. [hannosch] >>> >>> One month later we changed it not to fork a process internally, so >>> this is what we've been using for supervisord configurations for >>> years. >> >> Heh, good. :) I've been using a lower level script (run.py or something, >> deep inside Zope) in supervisord that I guess does the same thing. > > So are they the same or not? If so, then we can stop feeling like > idiots for missing 'bin/instance console' and continuing to use runzope ;-) > I'm getting the impression 'bin/instance console' is just a convenience. Since plone.recipe.zope2instance puts the egg paths in the instance zope.conf, parts/instance/bin/runzope should be equivalent I think. Laurence From natea at jazkarta.com Wed Jan 6 15:30:08 2010 From: natea at jazkarta.com (Nate Aune) Date: Wed Jan 6 15:30:39 2010 Subject: [Framework-Team] incorrect URL for repoze.xmliter? Message-ID: <9a89227c1001060730o453259b7l7ca30af8de0c242b@mail.gmail.com> I just tried running the Plone 4 coredev buildout ( http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) with deco.cfg last night, and it was failing when trying to check out repoze.xmliter. So I had to change this line in experimental/deco.cfg to get the buildout to run: - repoze.xmliter = svn svn+ssh:// repoze@svn.repoze.org/svn/repoze.xmliter/trunk + repoze.xmliter = svn http://svn.repoze.org/repoze.xmliter/trunk/ Also added to the plone-deco issue tracker on google code: http://code.google.com/p/plone-deco/issues/detail?id=15 Nate -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20100106/db671a57/attachment.htm From mj at zopatista.com Wed Jan 6 15:44:54 2010 From: mj at zopatista.com (Martijn Pieters) Date: Wed Jan 6 15:45:23 2010 Subject: [Framework-Team] incorrect URL for repoze.xmliter? In-Reply-To: <9a89227c1001060730o453259b7l7ca30af8de0c242b@mail.gmail.com> References: <9a89227c1001060730o453259b7l7ca30af8de0c242b@mail.gmail.com> Message-ID: <21a6ef161001060744r30ff8599i9d140a92238d1b67@mail.gmail.com> 2010/1/6 Nate Aune : > I just tried running the Plone 4 coredev buildout (http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) with deco.cfg last night, and it was failing when trying to check out repoze.xmliter. So I had to change this line in experimental/deco.cfg to get the buildout to run: > > - repoze.xmliter??????????????????? = svn svn+ssh://repoze@svn.repoze.org/svn/repoze.xmliter/trunk > + repoze.xmliter??????????????????? = svn http://svn.repoze.org/repoze.xmliter/trunk/ That looks to me like the repoze svn over ssh repo is either down or blocked for you. Moreover, I strongly suspect the http:// repo view is read-only, and so you won't be able to commit back. The latter is probably not a problem for everyone, but may bite those that do have write access. For future reference, just create a new config called 'local.cfg', use the following contents to have the same effect: [buildout] extends = deco.cfg [sources] repoze.xmliter = svn http://svn.repoze.org/repoze.xmliter/trunk/ Or, for fun and profit, install mercurial and hgsubversion and replace the 'svn http' part with 'hg svn+http' and create a DCVS clone so you can make local changes while offline. -- Martijn Pieters From optilude+lists at gmail.com Wed Jan 6 15:41:04 2010 From: optilude+lists at gmail.com (Martin Aspeli) Date: Wed Jan 6 15:46:26 2010 Subject: [Framework-Team] Re: incorrect URL for repoze.xmliter? In-Reply-To: <9a89227c1001060730o453259b7l7ca30af8de0c242b@mail.gmail.com> References: <9a89227c1001060730o453259b7l7ca30af8de0c242b@mail.gmail.com> Message-ID: Nate Aune wrote: > I just tried running the Plone 4 coredev buildout > (http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) > with deco.cfg last night, and it was failing when trying to check out > repoze.xmliter. So I had to change this line in experimental/deco.cfg to > get the buildout to run: > > - repoze.xmliter = svn > svn+ssh://repoze@svn.repoze.org/svn/repoze.xmliter/trunk > > + repoze.xmliter = svn > http://svn.repoze.org/repoze.xmliter/trunk/ > > Also added to the plone-deco issue tracker on google code: > http://code.google.com/p/plone-deco/issues/detail?id=15 This happens because you don't have commit privileges in the repoze svn. Leaving it with the public URL is better, though. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book From hanno at hannosch.eu Wed Jan 6 19:07:49 2010 From: hanno at hannosch.eu (Hanno Schlichting) Date: Wed Jan 6 19:08:17 2010 Subject: [Framework-Team] Re: Plone 4 - holidays are over :) In-Reply-To: References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <4B42AA5D.3020404@gmail.com> <5cae42b21001042048r519f9ffp9959a31f9353fcba@mail.gmail.com> Message-ID: <5cae42b21001061107s665446d6ge6f45f8e1f9d75db@mail.gmail.com> On Wed, Jan 6, 2010 at 1:52 PM, Laurence Rowe wrote: > 2010/1/6 Alex Clark : >> So are they the same or not? If so, then we can stop feeling like >> idiots for missing 'bin/instance console' and continuing to use runzope ;-) >> I'm getting the impression 'bin/instance console' is just a convenience. In the end both of them prepare an OS environment and execute Zope2/Startup/run.py. The main difference is that bin/instance is easier to type and is a Python script. "sh parts/instance/runzope" is a Unix shell script, so it's not available on all platforms. And in the zope2instance version used for Plone 4 runzope does no longer exist. > Since plone.recipe.zope2instance puts the egg paths in the instance > zope.conf, parts/instance/bin/runzope should be equivalent I think. Not quite. The recipe used to construct a Python path and put it into runzope ;-) But luckily we don't have to do that anymore, as buildout takes care of all that script generation stuff and constructing the right sys.path for us. Hanno From steve at dcn.org Wed Jan 6 19:02:45 2010 From: steve at dcn.org (Steve McMahon) Date: Wed Jan 6 19:11:27 2010 Subject: [Framework-Team] Plone 4 - holidays are over :) In-Reply-To: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> Message-ID: <26a908b51001061102s57fbe3c5u80464bf2ff13b38a@mail.gmail.com> Regarding the AJAX dialog problems, I just haven't gotten to those because of holiday busyness. I've watched them as they've come in, and they all look like they should be easily fixable. I'll make every effort to get to them soon! I've mainly been checking with Eric on which dialogs would benefit from AJAX. This is all convenience work, so if there's any dialog that is resistant to full fixup, we can easily omit it from the AJAX handling. All of these are set up in a single js file that's part of CMFPlone. Steve On Mon, Jan 4, 2010 at 11:42 AM, Hanno Schlichting wrote: > Heya. > > Some of us have been busy over the holiday season and worked a bit > more on Plone 4. The next question now is: > > ... > JS dialogs > #9805, #9806, #9921, #9693, #9957, #9964, #9977 > > All of these essentially mean that an operation done in a pop-up > doesn't redirect and reload a new page. So any kind of feedback > (positive, reconfirmation and failures) is lost. The other problem is > that the original page (shown in the background of the dialog) might > show information that is changing as a result of the dialog action. > For example publishing an object in a dialog, needs to refresh the > page, as its workflow state needs to be reflected, the item might now > show up in the navigation tree, a calendar or any other type of > portlet. > > It's a bit sad to see these problems, as we have already encountered > all of them, when first applying AJAX/KSS in the early Plone 3 stages. > We ended up reverting to a non-AJAX UI for most things, as almost all > of our UI actions can have arbitrary effects. > > I'm afraid that we need to re-evaluate all actions that use the new > dialogs and discuss them. We haven't had a PLIP review of the > individual dialogs. I think we have missed to pass on the hard earned > knowledge learned from the early Plone 3.0 days, but luckily it's not > too late. > ...______________________________ > _________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20100106/b1db71bf/attachment-0001.htm From ems174 at psu.edu Wed Jan 6 20:18:05 2010 From: ems174 at psu.edu (Eric Steele) Date: Wed Jan 6 20:18:22 2010 Subject: [Framework-Team] Plone 4 - holidays are over :) In-Reply-To: <26a908b51001061102s57fbe3c5u80464bf2ff13b38a@mail.gmail.com> References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> <26a908b51001061102s57fbe3c5u80464bf2ff13b38a@mail.gmail.com> Message-ID: <467A4A10-5B37-4159-A3A9-45270651F4AD@psu.edu> On Jan 6, 2010, at 2:02 PM, Steve McMahon wrote: > Regarding the AJAX dialog problems, I just haven't gotten to those because of holiday busyness. I've watched them as they've come in, and they all look like they should be easily fixable. I'll make every effort to get to them soon! > > I've mainly been checking with Eric on which dialogs would benefit from AJAX. This is all convenience work, so if there's any dialog that is resistant to full fixup, we can easily omit it from the AJAX handling. All of these are set up in a single js file that's part of CMFPlone. > > Steve Thanks for the update, Steve. Let me know if there's anything I can do to help. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20100106/d257d642/attachment.htm From tseaver at palladion.com Wed Jan 6 20:21:51 2010 From: tseaver at palladion.com (Tres Seaver) Date: Wed Jan 6 20:22:26 2010 Subject: [Framework-Team] Re: incorrect URL for repoze.xmliter? In-Reply-To: References: <9a89227c1001060730o453259b7l7ca30af8de0c242b@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Aspeli wrote: > Nate Aune wrote: >> I just tried running the Plone 4 coredev buildout >> (http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) >> with deco.cfg last night, and it was failing when trying to check out >> repoze.xmliter. So I had to change this line in experimental/deco.cfg to >> get the buildout to run: >> >> - repoze.xmliter = svn >> svn+ssh://repoze@svn.repoze.org/svn/repoze.xmliter/trunk >> >> + repoze.xmliter = svn >> http://svn.repoze.org/repoze.xmliter/trunk/ >> >> Also added to the plone-deco issue tracker on google code: >> http://code.google.com/p/plone-deco/issues/detail?id=15 > > This happens because you don't have commit privileges in the repoze svn. > Leaving it with the public URL is better, though. Why depend on SVN checkouts, rather than working to get the package released? Martin, you are the last one to touch it, looks like. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktE8N8ACgkQ+gerLs4ltQ5MigCdEgyuq5kEJfdVXNPix/SqiR9n TpIAoKrtxuqbdMGmg3UhJXUWWGVX2S+X =Hyv/ -----END PGP SIGNATURE----- From optilude+lists at gmail.com Thu Jan 7 00:54:04 2010 From: optilude+lists at gmail.com (Martin Aspeli) Date: Thu Jan 7 00:56:26 2010 Subject: [Framework-Team] Re: incorrect URL for repoze.xmliter? In-Reply-To: References: <9a89227c1001060730o453259b7l7ca30af8de0c242b@mail.gmail.com> Message-ID: Tres Seaver wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Martin Aspeli wrote: >> Nate Aune wrote: >>> I just tried running the Plone 4 coredev buildout >>> (http://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/) >>> with deco.cfg last night, and it was failing when trying to check out >>> repoze.xmliter. So I had to change this line in experimental/deco.cfg to >>> get the buildout to run: >>> >>> - repoze.xmliter = svn >>> svn+ssh://repoze@svn.repoze.org/svn/repoze.xmliter/trunk >>> >>> + repoze.xmliter = svn >>> http://svn.repoze.org/repoze.xmliter/trunk/ >>> >>> Also added to the plone-deco issue tracker on google code: >>> http://code.google.com/p/plone-deco/issues/detail?id=15 >> This happens because you don't have commit privileges in the repoze svn. >> Leaving it with the public URL is better, though. > > Why depend on SVN checkouts, rather than working to get the package > released? Martin, you are the last one to touch it, looks like. There is nothing in "proper" Plone that depends on this. experimental/deco.cfg is only really to be used by the Deco developers and is pretty rough still. A release would be good, it just isn't the top of the list. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book From limi at plone.org Sun Jan 10 03:49:46 2010 From: limi at plone.org (Alexander Limi) Date: Sun Jan 10 03:50:35 2010 Subject: [Framework-Team] Plone 4 - holidays are over :) In-Reply-To: References: <5cae42b21001041142p29307770k2b22382c3e4d112c@mail.gmail.com> Message-ID: On Mon, Jan 4, 2010 at 6:36 PM, Eric Steele wrote: > 2) We *really* need to move away from this whole "limi's theme" thing where > Alex is the point-of-failure for anything template/design related. Agreed. Denys has been picking up this, but anyone should feel free to help out. My main concern at the moment is the state of TinyMCE, I'll see if we can get some traction on this over the weekend with Rob and Sisi. I have been useless over the past week since I'm home sick, but > And on points 2 and 4...what does the UI team do these days, do we still > have one? > I've been silently trying to bootstrap a new one (mostly for Plone 5), and I have rallied them to get Plone 4 beta in shape. Currently my list is Rob, Denys, Sisi ? other suggestions welcome. Spare time and follow-through more important than skills (which can be learned ;). -- Alexander Limi ? http://limi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20100109/6f9b7358/attachment.htm From ems174 at psu.edu Tue Jan 12 02:27:40 2010 From: ems174 at psu.edu (Eric Steele) Date: Tue Jan 12 02:28:19 2010 Subject: [Framework-Team] User Preferences Form Message-ID: <823C253B-8F95-48DA-A4DA-616302A6E39D@psu.edu> FWT, Back in December, I asked Kees to think about what would be involved in modifying the two user preferences forms (prefs_user_details and personalize_form) to function in a way similar to the new registration forms. It seemed silly that we had this nice new, extensible way to add and remove fields on the registration forms, but those changes weren't reflected in the forms the user/admins would use to modify that data once the registration process was complete. With apologies to Kees, I'm just going to paste his response to me here... > Hi Eric, > > Some time ago you asked me to look into modifying prefs_user_details and > personalize_form, so they take extra fields defined in plone.app.users' forms > into account. I have finally thought about this, and gotten some of the work on > the way. I'll sketch my proposed approach here. > > It seems to me the best way to go is to modify the prefs_user_details and > personalize_form in such a way that work as @@register and @@new-user, that is > with a Zope form class. That seems more than a simple change, and i'm wondering > if this is what you had in mind. On the other hand, it does give us a chance to > clean up the code, and fix plip 9311 (https://dev.plone.org/plone/ticket/9311) > along the way. Please let me know if this approach is feasible. > > What i've done is create a new form ('@@change-member-details') for this. (This > form is intended to be renamed to '@@personalize_form' eventually, so it won't > break anything that relies in that name being there.) Currently it will only > display the 'fullname' field and update that. Eventually we could extend > IUserDataSchema so it also includes the extra fields which are currently in > personalize_form, like description ("Biography"), language, external editor, > wysiwyg editor, visible id's, etc. > > The code is in a new plone.app.users branch: > https://svn.plone.org/svn/plone/plone.app.users/branches/user_preferences_form/ > I've added a development buildout which uses this branch: > https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/experimental/user_preferences_form.cfg > (So one can just check out > https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0 and run > buildout -c experimental/user_preferences_form.cfg) > Note that CMFPlone should remain unchanged for now, until the new forms work. > > Kees I've unfortunately let this slip to the bottom of my todo list. I wanted to bring it here for more discussion and more eyes. I took a quick look at it and it seemed like a sane approach. I'd appreciate more eyes. Down the road, I can foresee a management ui that lists all of these fields and allows us to select to which of these 4 forms they're available. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20100111/05862c98/attachment.htm From G.J.Perrin at bton.ac.uk Wed Jan 13 14:31:25 2010 From: G.J.Perrin at bton.ac.uk (Graham Perrin) Date: Wed Jan 13 14:31:36 2010 Subject: [Framework-Team] Version support policy: revisions to page (with no change to policy) Message-ID: <60B35525-7041-4DB2-8C29-476D3AE69D06@bton.ac.uk> Casting a fresh eye over some areas of plone.org after a few months' focus elsewhere, the support policy wasn't immediately clear. (I'm familiar with the intention of the policy, but when I read it on screen, something seemed not quite right.) I have taken the liberty of editing . Not actually changing the policy, but: a) attention to order (beginning with definitions), headings etc. b) "will be" for major and minor versions that are not yet supported c) offering an example (the only one I know) of an exception to the security support policy. Re whilst I like the idea of a table, there's hilary over upgrade and support matrices for certain products ;) so I opted for bullets. In particular, I make clear the transition period that will apply between 4.0 and 4.1. If pull-quote style is not appropriate, we can revert those words to within the paragraph.? Steve's April 2009 revision is at , I won't be offended if you revert to that version (and I hope that FWT are not offended that I edited the page :) Regards Graham ? I gave up on attempts to edit the item further. Bugged by and by repeated > We couldn't reach the plone.org backend server, which probably means it's undergoing maintenance, and will be back in a bit. From m.van.rees at zestsoftware.nl Wed Jan 13 15:04:59 2010 From: m.van.rees at zestsoftware.nl (Maurits van Rees) Date: Wed Jan 13 15:30:53 2010 Subject: [Framework-Team] Version support policy: revisions to page (with no change to policy) In-Reply-To: <60B35525-7041-4DB2-8C29-476D3AE69D06@bton.ac.uk> References: <60B35525-7041-4DB2-8C29-476D3AE69D06@bton.ac.uk> Message-ID: <20100113150459.GB5228@kronos.zestsoftware.nl> On Wed, Jan 13, 2010 at 02:31:25PM +0000, Graham Perrin wrote: > Casting a fresh eye over some areas of plone.org after a few months' > focus elsewhere, the support policy wasn't immediately clear. > > (I'm familiar with the intention of the policy, but when I read it > on screen, something seemed not quite right.) > > I have taken the liberty of editing > http://plone.org/support/version-support-policy "4.x will be major." makes me think: 4.0, 4.1, 4.2 etc are major versions. And then the text says "4.1 and 4.2 will be minor." which makes me confused. I would say: "Plone 4 will be a major release." BTW, I have no access to the previous version of this document. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ What are you going to create today? From lists at zopyx.com Wed Jan 13 16:36:16 2010 From: lists at zopyx.com (Andreas Jung) Date: Wed Jan 13 16:36:25 2010 Subject: [Framework-Team] Accouncement for updated Zope versions due to XSS vulnerability Message-ID: <4B4DF680.9010701@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I think Plone users should get information about the updated Zope versions (2.8-2.12) released yesterday in order to fix the XSS vulnerability reported by Alex Limi. Is this on someone's radar? Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktN9oAACgkQCJIWIbr9KYzoVQCgzZosjhEkvHvJxlIy2II6DBM/ eVgAnREx2AJr4aAybchznz8CuHxxzIu3 =RGxj -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.plone.org/pipermail/framework-team/attachments/20100113/230fbe0d/lists.vcf From sivang at gmail.com Wed Jan 13 16:37:53 2010 From: sivang at gmail.com (Sivan Green) Date: Wed Jan 13 16:38:21 2010 Subject: [Framework-Team] Accouncement for updated Zope versions due to XSS vulnerability In-Reply-To: <4B4DF680.9010701@zopyx.com> References: <4B4DF680.9010701@zopyx.com> Message-ID: <9af54e6b1001130837m75d5e0b6i7ee8ea4c18e1d7cd@mail.gmail.com> So we should issue an informed warning and encourage to update together with update instructions. Have we tested that to no break current installs / buildouts ? Sivan On Wed, Jan 13, 2010 at 6:36 PM, Andreas Jung wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi there, > > I think Plone users should get information about the updated Zope versions > (2.8-2.12) released yesterday in order to fix the XSS vulnerability > reported > by Alex Limi. Is this on someone's radar? > > Andreas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAktN9oAACgkQCJIWIbr9KYzoVQCgzZosjhEkvHvJxlIy2II6DBM/ > eVgAnREx2AJr4aAybchznz8CuHxxzIu3 > =RGxj > -----END PGP SIGNATURE----- > > > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > > -- Best Regards, Sivan Green From lists at zopyx.com Wed Jan 13 17:31:38 2010 From: lists at zopyx.com (Andreas Jung) Date: Wed Jan 13 17:31:47 2010 Subject: [Framework-Team] Accouncement for updated Zope versions due to XSS vulnerability In-Reply-To: <9af54e6b1001130837m75d5e0b6i7ee8ea4c18e1d7cd@mail.gmail.com> References: <4B4DF680.9010701@zopyx.com> <9af54e6b1001130837m75d5e0b6i7ee8ea4c18e1d7cd@mail.gmail.com> Message-ID: <4B4E037A.7050805@zopyx.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sivan Green wrote: > So we should issue an informed warning and encourage to update > together with update instructions. Have we tested that to no break > current installs / buildouts ? > Full disclosure is available: https://bugs.launchpad.net/zope2/+bug/491224 I would not expect any issues with upgrading the Zope version. I updated a bunch of Plone 3.2 and 3.3 sites from various Zope 2.10 versions to the latest one - no issues - especially because the fix is a one-liner somewhere in the handler for the error messages. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktOA3oACgkQCJIWIbr9KYxXOwCgutkoudJ8AyiwKiv3KU0G4XsG eMYAoKgJY6+IDiDawy5OoJnj+qZ1wAaM =hxl3 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: lists.vcf Type: text/x-vcard Size: 316 bytes Desc: not available Url : http://lists.plone.org/pipermail/framework-team/attachments/20100113/b9636a76/lists.vcf From jonstahl at gmail.com Thu Jan 14 02:49:07 2010 From: jonstahl at gmail.com (Jon Stahl) Date: Thu Jan 14 02:49:37 2010 Subject: [Framework-Team] Notes from Joel on simplifying Plone Message-ID: Hi FWT! Per a brief conversation in #plone-framework tonight, I remembered that back in October, while I was on sabbatical, I actually got around to interviewing Joel Burton about how he thinks Plone could most effectively be simplified for greater "approachability." For what it's worth, here are my somewhat-cleaned-up notes from that 2-3 hour conversation. I hope it's helpful to you. I know that some of it is already a little bit out of date (woohoo!). best, jon --------- Since 2006, Plone has gotten vastly more powerful and flexible, but it has also become more complex and harder to approach for new site integrators. ?This is not a new observation. Most of the increased complexity stems from our past choices to adopt new technologies that we didn't build ourselves, without adequately considering how well they fit our average integrator's knowledge or skills. ?In many cases these new technologies offered considerable benefits, but also had significant missing features or confusing/awkward aspects that we failed to address. The good news it that there are fairly straightforward ways of addressing most of these issues. ?The result will be vastly increased satisfaction for the vast majority of our everyday site builders, and renewed energy and enthusiasm in the Plone community. Joel Burton and I spent a few hours talking about some of these issues, and came up with the following list of challenges and opportunities. 1) Viewlets and viewlet managers. While viewlets and viewlet managers provide some clear benefits to add-on product authors, they are very clumsy and confusing for more basic theming tasks. The biggest specific problem is that our current design doesn't allow us to move viewlets between viewlet managers without writing code and ZCML. ?This makes a complete through-the-web viewlet manager like GloWorm impossible to realize. We need to rethink the design of viewlets (in a backwards compatible way) so that a tool like GloWorm can move viewlets, create new viewlets and customize existing viewlets through-the-web, THEN dump the results to a disk-based product. ? We believe that this kind of workflow would transform average integrators' loathing of viewlets into love. 2) ZCML-wired page templates It is currently too difficult to override a default Plone template. We need to have a mainstream, best-practice way "wire-by-name" way to add new templates, override templates in themes (layers) and override things that are already overridden. Jbot is a good portion of the way there, we don't know if it can go all the way, but we certainly hope so. ? ?We need to move this type of solution to the front and center of our template customization story. 3) Product installation with buildout Buildout offers many benefits, but also presents a learning curve for new site integrators, especially w/r/t add-on product installation. Some specific challenges and ideas for improvement include: - There's no obvious, easy way to find out the name of an egg from the product listing on Plone.org. ?This is easy to fix in PSC. - The redundant need to add many products to both "eggs" and "zcml" is very, very confusing and frustrating to new users. ?With Plone 3.3, we finally have the capability to use autoinclude, but we have to aggressively get product authors to update their products to take advantage of this capability, or else sprint through the collective and do it for them. Let's get this done! - Right now, if buildout fails (e.g. because it can't download something), it often kills your existing site. ?That's not cool. ?Even some basic sanity checking (download all eggs before touching the existing install) would help a lot. - Buildout offers opaque and confusing error messages. ?This really needs to change, but we know it requires some pretty sophisticated attention. - The "apache-style" buildout.cfg file is inherently intimidating to new site developers. ?At first, they just want any easy way to install add-on products. ?We used to have that -- just unzip stuff into the Products folder. ?We need to bring back this idea: we envision a "products.d" folder where you can drop an egg, or a file named "my.egg.cfg" and it just works. ? This will also greatly increase our deb/rpm friendliness, since installing products via deb/rpm would just involve dropping those products in the folder. - Pinning does not currently lead to predictable, repeatable deployments. Pinning is also still very confusing. ?Even a good, commented-out example of pinning would help. ?We're not sure how it work work, but some approach to auto pinning would be excellent; people expect if they have the same buildout file and run it on their server, they'll get the same stuff. ?We need to come up with some way to "bake" a buildout (e.g. bin/buildout --generate-deployment-file) so we can guarantee that a buildout will always get the exact same code. 4) Product uninstallation While many more experienced developers don't often uninstall products, or test products in a throwaway buildout, our new users don't have the skill/experience to do this. ?And many of our products don't uninstall cleanly. ?This creates massive early-stage frustration for new site integrators. ?Part of the problem is that GenericSetup doesn't have support for uninstalling everything it can install; we need to address this with both code and documentation. ?Then, we need to educate add-on product authors to create uninstall profiles. Other minor things 5) zopeskel/paster ?- but the recipes are a sink of super-advanced practices ie, most people still use cmf skins but the skeleton to "build archetype product" doesn't make a skins/ folder. ?- reposition as average integrator tool ?- in general, tho', I'm still puzzled why we bash agx. ?it's a huge hit with integrators, and the generated code quality is quite good ?- "designing content types" was our "killer feature" 6) ldap integration [seems to be harder than for other cmses, no direct experience on this myself] Things we need to focus on in a strategic planning call: - Name the audience we aspire to serve, what we expect of them, and what they can expect of us. ?- Some description of external environment + our positioning in it over the next 2-3 years. - What our core cultural values are, and how to structure our process so that we successfully deliver on those values. From optilude+lists at gmail.com Thu Jan 14 05:32:19 2010 From: optilude+lists at gmail.com (Martin Aspeli) Date: Thu Jan 14 05:32:59 2010 Subject: [Framework-Team] Re: Notes from Joel on simplifying Plone In-Reply-To: References: Message-ID: Thanks for doing this, Jon! > Most of the increased complexity stems from our past choices to adopt > new technologies that we didn't build ourselves, without adequately > considering how well they fit our average integrator's knowledge or > skills. In many cases these new technologies offered considerable > benefits, but also had significant missing features or > confusing/awkward aspects that we failed to address. And sometimes failed to deliver features present in the technologies they were intended to replace, leading to a hybrid approach that is more confusing still. > 1) Viewlets and viewlet managers. > > While viewlets and viewlet managers provide some clear benefits to > add-on product authors, they are very clumsy and confusing for more > basic theming tasks. The biggest specific problem is that our current > design doesn't allow us to move viewlets between viewlet managers > without writing code and ZCML. This makes a complete through-the-web > viewlet manager like GloWorm impossible to realize. > > We need to rethink the design of viewlets (in a backwards compatible > way) so that a tool like GloWorm can move viewlets, create new > viewlets and customize existing viewlets through-the-web, THEN dump > the results to a disk-based product. We believe that this kind of > workflow would transform average integrators' loathing of viewlets > into love. A bit aha for me when we started talking about Deco was that the viewlets use case is basically this: A third party product needs to plug itself into a part of Plone's UI in a semantic location. For example, plone.app.iterate puts a message about the existence of a working copy into a space you could logically call the "notice area". It can do this quite nicely with marker interfaces. The use case for viewlets is *not* to replace ZPT macros as a way to package up re-usable components. Unfortunately, that's what we did. You could argue that zope.conentprovider (the low-level package on which zope.viewlet is built - basically, a contentprovider is something you can insert via the provides: expression) is such a thing. However, there's no easy way to register a content provider, so we have viewlets instead. The ability to move/re-order viewlets is semi-useful, but I think a model based on moving named things around a template is more useful still. The viewlet manager abstraction is still pretty arbitrary, not at least because we use names based on location ("above content") instead of meaning ("notice area"). Of course, the solution to all this is likely to be: - Deliverance/XDV for broad-brush re-branding - Deco/Blocks/Tiles for pluggable, re-organisable UIs In Plone 5, I hope we'll have three or four viewlet managers, representing such thing as "HTML head", "notice area" or "end of page" (for late-bind JavaScript stuff). Some of these may even be contained within tiles, allowing administrators to move the areas around on the site layout. > 2) ZCML-wired page templates > > It is currently too difficult to override a default Plone template. > We need to have a mainstream, best-practice way "wire-by-name" way to > add new templates, override templates in themes (layers) and override > things that are already overridden. > > Jbot is a good portion of the way there, we don't know if it can go > all the way, but we certainly hope so. We need to move this type of > solution to the front and center of our template customization story. I couldn't agree more. I'm leaning toward something that allows people to use Grok-style convention-over-configuration when they want a Python class, but allows configuration without the class (and allows you to add the class later if you decide you need it). This needs to work the same for overrides (which z3c.jbot handles pretty well) and new templates (which it doesn't address at all). The basic principle needs to be that you can get pretty far with just TAL-in-a-directory. We also want TTW customisation with filesystem export, which David Glick is working on right now. ;-) > 3) Product installation with buildout > > Buildout offers many benefits, but also presents a learning curve for > new site integrators, especially w/r/t add-on product installation. > Some specific challenges and ideas for improvement include: > > - There's no obvious, easy way to find out the name of an egg from the > product listing on Plone.org. This is easy to fix in PSC. > > - The redundant need to add many products to both "eggs" and "zcml" is > very, very confusing and frustrating to new users. With Plone 3.3, we > finally have the capability to use autoinclude, but we have to > aggressively get product authors to update their products to take > advantage of this capability, or else sprint through the collective > and do it for them. Let's get this done! +1 As a general principle: if the package is a Plone Product (as opposed to a lower level library) it should have this in setup.py: entry_points = """\ [z3c.autoinclude.plugin] target = plone """ > - Right now, if buildout fails (e.g. because it can't download > something), it often kills your existing site. That's not cool. Even > some basic sanity checking (download all eggs before touching the > existing install) would help a lot. +1 - this would probably require some sandboxing support in buildout itself. > - Buildout offers opaque and confusing error messages. This really > needs to change, but we know it requires some pretty sophisticated > attention. +1 > - The "apache-style" buildout.cfg file is inherently intimidating to > new site developers. At first, they just want any easy way to install > add-on products. We used to have that -- just unzip stuff into the > Products folder. We need to bring back this idea: we envision a > "products.d" folder where you can drop an egg, or a file named > "my.egg.cfg" and it just works. This will also greatly increase our > deb/rpm friendliness, since installing products via deb/rpm would just > involve dropping those products in the folder. This is easier said than done, because you need dependency tracking. I think a my.egg.cfg file that is semantically equivalent to adding 'my.egg' to a line in buildout could work. It'd be pretty easy to write a buildout extension to do that, for instance. > - Pinning does not currently lead to predictable, repeatable > deployments. Pinning is also still very confusing. Even a good, > commented-out example of pinning would help. We're not sure how it > work work, but some approach to auto pinning would be excellent; > people expect if they have the same buildout file and run it on their > server, they'll get the same stuff. We need to come up with some way > to "bake" a buildout (e.g. bin/buildout --generate-deployment-file) so > we can guarantee that a buildout will always get the exact same code. This is imminently feasible, and we do it in some of our builds (the uber-buildouts in the collective has an example). When you pin properly, you do get repeatable, offline builds. However, you need to know how to do it. > 4) Product uninstallation > > While many more experienced developers don't often uninstall products, > or test products in a throwaway buildout, our new users don't have the > skill/experience to do this. And many of our products don't uninstall > cleanly. This creates massive early-stage frustration for new site > integrators. Part of the problem is that GenericSetup doesn't have > support for uninstalling everything it can install; we need to address > this with both code and documentation. Then, we need to educate > add-on product authors to create uninstall profiles. This is hard, but important. > Other minor things > > 5) zopeskel/paster > - but the recipes are a sink of super-advanced practices ie, most > people still use cmf skins but the skeleton to "build archetype > product" doesn't make a skins/ folder. > - reposition as average integrator tool > - in general, tho', I'm still puzzled why we bash agx. it's a huge > hit with integrators, and the generated code quality is quite good > - "designing content types" was our "killer feature" +1 to all of that. I'm quite frustrated that none of the BBQ sprint ZopeSkel improvements have been released yet, and they seem to be bit-rotting. This is an easy thing for someone to own, and an important one. > 6) ldap integration [seems to be harder than for other cmses, no > direct experience on this myself] I think this is largely solved with plone.app.ldap, save for a few UI bugs in that package. It's actually pretty easy these days to get a sensible LDAP configuration up and running. Fine-tuning is harder, but that's normally because corporate AD/LDAP installations all differ. > Things we need to focus on in a strategic planning call: > > - Name the audience we aspire to serve, what we expect of them, and > what they can expect of us. +1 > - Some description of external environment + our positioning in it > over the next 2-3 years. +1 > - What our core cultural values are, and how to structure our process > so that we successfully deliver on those values. +1 All of these are a bit too abstract to comment on, but very sensible. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book From raphael.ritz at incf.org Thu Jan 14 08:01:47 2010 From: raphael.ritz at incf.org (Raphael Ritz) Date: Thu Jan 14 08:02:04 2010 Subject: [Framework-Team] Notes from Joel on simplifying Plone In-Reply-To: References: Message-ID: <4B4ECF6B.108@incf.org> Jon Stahl wrote: > Hi FWT! > Hi Jon, thanks for posting this! For now just one comment from my side: [..] > > - The "apache-style" buildout.cfg file is inherently intimidating to > new site developers. At first, they just want any easy way to install > add-on products. We used to have that -- just unzip stuff into the > Products folder. We need to bring back this idea: we envision a > "products.d" folder where you can drop an egg, or a file named > "my.egg.cfg" and it just works. This will also greatly increase our > deb/rpm friendliness, since installing products via deb/rpm would just > involve dropping those products in the folder. > http://pypi.python.org/pypi/buildout.eggnest/ seems pretty close to that if I'm not mistaken. With a naming convention on the file name for the [eggnest] part we should be able to realize the above. Raphael From hanno at hannosch.eu Sun Jan 17 15:52:41 2010 From: hanno at hannosch.eu (Hanno Schlichting) Date: Sun Jan 17 15:53:11 2010 Subject: [Framework-Team] Re: Body class In-Reply-To: <5af21ed11001170724x1dbc223em9bf335122394a8c7@mail.gmail.com> References: <5af21ed11001170724x1dbc223em9bf335122394a8c7@mail.gmail.com> Message-ID: <5cae42b21001170752m793f6d6ajc4dd9bf391c57f7a@mail.gmail.com> On Sun, Jan 17, 2010 at 4:24 PM, Martin Aspeli wrote: > Any chance we could put this in a separate view utility instead of the > @@plone one, so that it's more sane to override? Yeah. With bodyClass already being on that view, it felt ok-ish. But I guess there's a couple of "visual policy" methods in there which should go into their own view somewhere in plone.app.layout. Just looking at the methods, I'd move the following to a new view (leaving BBB support in the old place): mark_view have_portlets hide_columns renderBase bodyClass These all feel like things that influence CSS classes or UI policy in some way. Hanno From optilude+lists at gmail.com Sun Jan 17 15:55:11 2010 From: optilude+lists at gmail.com (Martin Aspeli) Date: Sun Jan 17 16:03:07 2010 Subject: [Framework-Team] Re: Body class In-Reply-To: <5cae42b21001170752m793f6d6ajc4dd9bf391c57f7a@mail.gmail.com> References: <5af21ed11001170724x1dbc223em9bf335122394a8c7@mail.gmail.com> <5cae42b21001170752m793f6d6ajc4dd9bf391c57f7a@mail.gmail.com> Message-ID: <5af21ed11001170755u3ddd1652sc6a7d8ad08d8a873@mail.gmail.com> Hi, 2010/1/17 Hanno Schlichting : > On Sun, Jan 17, 2010 at 4:24 PM, Martin Aspeli wrote: >> Any chance we could put this in a separate view utility instead of the >> @@plone one, so that it's more sane to override? > > Yeah. With bodyClass already being on that view, it felt ok-ish. But I > guess there's a couple of "visual policy" methods in there which > should go into their own view somewhere in plone.app.layout. +1 > Just looking at the methods, I'd move the following to a new view > (leaving BBB support in the old place): > > mark_view > have_portlets > hide_columns > renderBase > bodyClass > > These all feel like things that influence CSS classes or UI policy in some way. I think mark_view should probably stay, or at least be separate. It's both fundamental to other functionality and easy to screw up. +1 for the others, though. Martin From wichert at wiggy.net Sun Jan 17 20:19:23 2010 From: wichert at wiggy.net (Wichert Akkerman) Date: Sun Jan 17 20:19:36 2010 Subject: [Framework-Team] Re: Body class In-Reply-To: <5cae42b21001170752m793f6d6ajc4dd9bf391c57f7a@mail.gmail.com> References: <5af21ed11001170724x1dbc223em9bf335122394a8c7@mail.gmail.com> <5cae42b21001170752m793f6d6ajc4dd9bf391c57f7a@mail.gmail.com> Message-ID: <4B5370CB.5020505@wiggy.net> On 2010-1-17 16:52, Hanno Schlichting wrote: > On Sun, Jan 17, 2010 at 4:24 PM, Martin Aspeli wrote: >> Any chance we could put this in a separate view utility instead of the >> @@plone one, so that it's more sane to override? > > Yeah. With bodyClass already being on that view, it felt ok-ish. But I > guess there's a couple of "visual policy" methods in there which > should go into their own view somewhere in plone.app.layout. > > Just looking at the methods, I'd move the following to a new view > (leaving BBB support in the old place): > > mark_view > have_portlets > hide_columns > renderBase > bodyClass is_view_template or whatever it is that manages IViewView. We've found it to be very painful to manage IViewView now. In particular it appears to be impossible to set when you render a template from a browser view. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From hanno at hannosch.eu Sun Jan 17 20:36:25 2010 From: hanno at hannosch.eu (Hanno Schlichting) Date: Sun Jan 17 20:36:54 2010 Subject: [Framework-Team] Re: Body class In-Reply-To: <4B5370CB.5020505@wiggy.net> References: <5af21ed11001170724x1dbc223em9bf335122394a8c7@mail.gmail.com> <5cae42b21001170752m793f6d6ajc4dd9bf391c57f7a@mail.gmail.com> <4B5370CB.5020505@wiggy.net> Message-ID: <5cae42b21001171236x43614137u1f8cad6607631133@mail.gmail.com> On Sun, Jan 17, 2010 at 9:19 PM, Wichert Akkerman wrote: > On 2010-1-17 16:52, Hanno Schlichting wrote: >> >> mark_view >> have_portlets >> hide_columns >> renderBase >> bodyClass > > is_view_template or whatever it is that manages IViewView. We've found it to > be very painful to manage IViewView now. In particular it appears to be > impossible to set when you render a template from a browser view. mark_view actually sets the IViewView interface. The main_template does: view nocall:view | nocall: plone_view; dummy python: plone_view.mark_view(view); which you should be able to do in any template that doesn't use main_template. Otherwise it should work just fine to add "implements(IViewView)" to your browser view class. But maybe I'm missing what exactly you want to do. Hanno From wichert at wiggy.net Sun Jan 17 20:38:38 2010 From: wichert at wiggy.net (Wichert Akkerman) Date: Sun Jan 17 20:38:48 2010 Subject: [Framework-Team] Re: Body class In-Reply-To: <5cae42b21001171236x43614137u1f8cad6607631133@mail.gmail.com> References: <5af21ed11001170724x1dbc223em9bf335122394a8c7@mail.gmail.com> <5cae42b21001170752m793f6d6ajc4dd9bf391c57f7a@mail.gmail.com> <4B5370CB.5020505@wiggy.net> <5cae42b21001171236x43614137u1f8cad6607631133@mail.gmail.com> Message-ID: <4B53754E.60808@wiggy.net> On 2010-1-17 21:36, Hanno Schlichting wrote: > On Sun, Jan 17, 2010 at 9:19 PM, Wichert Akkerman wrote: >> On 2010-1-17 16:52, Hanno Schlichting wrote: >>> >>> mark_view >>> have_portlets >>> hide_columns >>> renderBase >>> bodyClass >> >> is_view_template or whatever it is that manages IViewView. We've found it to >> be very painful to manage IViewView now. In particular it appears to be >> impossible to set when you render a template from a browser view. > > mark_view actually sets the IViewView interface. The main_template does: > > view nocall:view | nocall: plone_view; > dummy python: plone_view.mark_view(view); > > which you should be able to do in any template that doesn't use > main_template. Otherwise it should work just fine to add > "implements(IViewView)" to your browser view class. > > But maybe I'm missing what exactly you want to do. This: class MyView(BrowserView): def __call__(self): return aq_inner(self.context).some_template() and make sure that IViewView is set when some_template is rendered. Currently that is impossible since mark_view does checks that are impossible to influence from the outside, and there is nothing MyView could set IViewView on itself. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From hanno at hannosch.eu Sun Jan 17 21:05:53 2010 From: hanno at hannosch.eu (Hanno Schlichting) Date: Sun Jan 17 21:06:22 2010 Subject: [Framework-Team] Re: Body class In-Reply-To: <4B53754E.60808@wiggy.net> References: <5af21ed11001170724x1dbc223em9bf335122394a8c7@mail.gmail.com> <5cae42b21001170752m793f6d6ajc4dd9bf391c57f7a@mail.gmail.com> <4B5370CB.5020505@wiggy.net> <5cae42b21001171236x43614137u1f8cad6607631133@mail.gmail.com> <4B53754E.60808@wiggy.net> Message-ID: <5cae42b21001171305q1ce8d342l77cb685ae4da3577@mail.gmail.com> On Sun, Jan 17, 2010 at 9:38 PM, Wichert Akkerman wrote: > class MyView(BrowserView): > ? ?def __call__(self): > ? ? ? ?return aq_inner(self.context).some_template() > > and make sure that IViewView is set when some_template is rendered. > Currently that is impossible since mark_view does checks that are impossible > to influence from the outside, and there is nothing MyView could set > IViewView on itself. Right. I have to admit that I don't fully understand IViewView. It currently suggests that for any published url, there's "one view" representing this url and it can be marked as "the view of an object". But our pages are composed of many views, with skins there aren't any underlying views, though we somehow try to treat the ploneview as a surrogate. Once you turn main_template into a browser page it becomes even less clear what "the view" object is. And as you noticed it's impossible to get to that one mysterious "view" from somewhere in the layout stack. The only things you can access from all places are context and request. I think we might want to add a marker to the request instead or in addition to the current approach, similar to how "disable editable border" and "hide columns" work. I had a similar use-case recently, where I needed to make some of the content menus conditional on whether or not you are on "the folder contents page". In the end I had to go down to something like "alsoProvides(request, IContentsPage)" and check that in code in the menus. The "view" just isn't accessible anywhere outside the one template it is driving. Hanno