From ems174 at psu.edu Tue Aug 4 20:21:52 2009 From: ems174 at psu.edu (Eric Steele) Date: Tue Aug 4 20:22:05 2009 Subject: [Framework-Team] #9310 (User registration process more flexible) Message-ID: <27A81F1A-003F-40B1-999E-4347ECFFF2B6@psu.edu> FWT, As previously noted, https://dev.plone.org/plone/ticket/9310 has been abandoned by the implementer due to time constraints. Given the current state of the code and the scope of the proposal, we're not going see this one completed for 4.0. I'd like to see if we can get *something* into 4.0 that could be built upon in a 4.x release to make this happen though. Are there steps in the right direction that we could take? Alex Clark has expressed a willingness to contribute if time allows. Eric From psucorp at grinchcentral.com Wed Aug 5 20:00:15 2009 From: psucorp at grinchcentral.com (Erik Rose) Date: Wed Aug 5 20:00:24 2009 Subject: [Framework-Team] Minutes: 8 August 2009 Message-ID: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> Image IDs (https://dev.plone.org/plone/ticket/9186): * Erik is finding this less difficult than he feared. Probably won't be extending it to apply to the File type, as that introduces the scenario where downloading a Word doc results in a file whose name doesn't end in ".doc", causing problems opening it. Brilliant suggestions regarding MIME type guessing are welcome. Role revocation on user deletion (https://dev.plone.org/plone/ticket/8901 ): * Erik doesn't expect to have time for this one; the right way to go about it is probably to disambiguate user ID and login name once and for all in the Plone codebase and then make sure user IDs are never reused. More flexible user registration (https://dev.plone.org/plone/ticket/ 9310): * The author of this PLIP has abandoned it citing time constraints. There's nothing we can really do to make it possible for a 4.x release unless somebody writes the code to generate the registration form based on member properties, which comprises most of the work anyway. Python 2.6, Zope 2.12 (https://dev.plone.org/plone/ticket/8808): * David ported the migration procedure to GS and moved it into plone.app.upgrade. Ran a migration from a stock Plone 2.5 to 4.0, and it seemed to work, though he welcomes more thorough testing. * There are still some tests that interfere with each other and fail when they're all run together; that has to be ironed out. * IPublishTraverse is used where ITraverse should be; that's why some linkintegrity tests are failing. * All the globalization in templates is gone now, and Plone's templates have been updated to not use it. This originated in the 5.x branch as a speed optimization, but does it deliver? It's going to break a lot of products. MatthewWilkes will talk to Hanno about this and see if it really did help performance. The FWT is concerned about breaking every product if it turns our we're just replacing one very slow thing with many less-slow things. Cheers, Erik Rose From psucorp at grinchcentral.com Wed Aug 5 20:05:05 2009 From: psucorp at grinchcentral.com (Erik Rose) Date: Wed Aug 5 20:05:13 2009 Subject: [Framework-Team] More Minutes: 8 August 2009 Message-ID: <8CE572A5-B5B3-449C-ADDE-0B054D2A68EA@grinchcentral.com> Claris Emailer's 10-minute outgoing delay, how I miss thee. Here's are the items that were scrolled off my screen: Allow views to override skin layer elements easily (https://dev.plone.org/plone/ticket/9284 ): * Matthew will start his PLIP on Friday. Geir's PLIPs: * Geir and some folks from Four Digits are going to sprint 3 days before the PLIP deadline and, defying the very laws of physics, still plan to get it all done. Cheers, Erik Rose From davidglick at onenw.org Wed Aug 5 20:18:58 2009 From: davidglick at onenw.org (David Glick) Date: Wed Aug 5 20:19:28 2009 Subject: [Framework-Team] Minutes: 8 August 2009 In-Reply-To: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> Message-ID: <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> On Aug 5, 2009, at 1:00 PM, Erik Rose wrote: > Python 2.6, Zope 2.12 (https://dev.plone.org/plone/ticket/8808): > > * David ported the migration procedure to GS and moved it into > plone.app.upgrade. Ran a migration from a stock Plone 2.5 to 4.0, > and it seemed to work, though he welcomes more thorough testing. Actually Hanno did the work here, and I just copied it :) > * IPublishTraverse is used where ITraverse should be; that's why some > linkintegrity tests are failing. Actually they both need to be used. And that's just a guess -- I haven't actually looked at this yet. David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidglick@onenw.org 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 From apm13 at columbia.edu Wed Aug 5 20:45:07 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Wed Aug 5 20:45:13 2009 Subject: [Framework-Team] Minutes: 8 August 2009 In-Reply-To: <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> Message-ID: <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> On Wed, Aug 5, 2009 at 1:18 PM, David Glick wrote: > On Aug 5, 2009, at 1:00 PM, Erik Rose wrote: >> >> Python 2.6, Zope 2.12 (https://dev.plone.org/plone/ticket/8808): >> >> * David ported the migration procedure to GS and moved it into >> ?plone.app.upgrade. Ran a migration from a stock Plone 2.5 to 4.0, >> ?and it seemed to work, though he welcomes more thorough testing. > > Actually Hanno did the work here, and I just copied it :) > >> * IPublishTraverse is used where ITraverse should be; that's why some >> ?linkintegrity tests are failing. > > Actually they both need to be used. ?And that's just a guess -- I haven't > actually looked at this yet. It doesn't look like there's any way to override OFS traversal using a component (other than a view of course). Perhaps we should just be using the existing custom __getitem__ that's already in BaseObject/BaseFolder instead of traversal magic. Alec From hanno at hannosch.eu Wed Aug 5 21:15:40 2009 From: hanno at hannosch.eu (Hanno Schlichting) Date: Wed Aug 5 21:15:45 2009 Subject: [Framework-Team] Minutes: 8 August 2009 In-Reply-To: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> Message-ID: <5cae42b20908051415s44fa2dc0h8aabcd34dcce0857@mail.gmail.com> On Wed, Aug 5, 2009 at 10:00 PM, Erik Rose wrote: > ?* All the globalization in templates is gone now, and Plone's > ? templates have been updated to not use it. This originated in the > ? 5.x branch as a speed optimization, but does it deliver? It's > ? going to break a lot of products. MatthewWilkes will talk to > ? Hanno about this and see if it really did help performance. The > ? FWT is concerned about breaking every product if it turns our > ? we're just replacing one very slow thing with many less-slow > ? things. This change is not only and maybe not even primarily a speed optimization. When running performance tests against current Plone 4 for typical full-fledged pages like a document view, edit screens or folder contents views, there is hardly any performance difference between Plone 4.0 and 3.3. Thus there doesn't seem to be an immediate performance gain for those kind of pages, but neither is there any increased cost. One thing where you should be able to measure a significant difference is on classic portlets. These used to set up all the globalize stuff again for the separate expression context of the classic template, making them quite a bit slower. Executing the globalize hack twice or even many times was certainly quite a bit of a difference. The reasons why I'm very much in favor of removing the globalize hack are different ones: Obviously the way it is done is an utter hack. Walking up stack frames to inject things into a higher global scope is very evil. Second the "globalized" names are today a random set of shortcuts, which have little to do with the typical need inside templates. They started out a point where access to a set of tools was essentially the whole Plone API, but this isn't the case anymore. Now they just make it harder to understand template code as there is no way to find the actual code path from for example the "syntool" name inside a template to the actual implementation. They obscure templates for little to no benefit, as most often the real call is a one-liner itself and context/portal_syndication gives a much better searchable term. Another point is that they make templates rely on execution order of the whole macros system. They only work when called after the globalize hack has been executed but not in isolation. This also leads to problems when trying to move templates into more reusable packages as it becomes very hard to see the actual dependencies of the template. What looks like locally defined shortcuts turn out to be "oh and btw. I need those other ten packages"-type dependencies. It would have been much harder to understand and disentangle dependencies between packages on trunk, if those hacked in names still would have been in place. If we want to make things optional to get people a more speedy and less memory hungry Plone, having a central place that binds them all doesn't work. And last removing these calls from a centralized place makes both profiling of what actually contributes to the slowness of Plone much easier and allows for easier deprecation of some of the so far globalized names. For example many of the actual performance improvements on trunk result from changes to the way actions are looked up. To make these work, all of the "actions, keyed_actions, user_actions, workflow_actions, folder_actions, global_actions" names of todays globalize thing need to be deprecated and replaced. Instead of always having these defined everywhere, they need to be turned into a pattern where only the viewlet / macro that actually shows the particular action category also calls and evaluates those actions. For example hiding the personal bar in the UI today doesn't make a difference since all the actions in that category are still evaluated and their conditions checked. Even though nobody will ever show any of them. Maybe I forgot other reasons why this particular hack is considered one ;-) Hanno From apm13 at columbia.edu Wed Aug 5 21:27:27 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Wed Aug 5 21:27:36 2009 Subject: [Framework-Team] Minutes: 8 August 2009 In-Reply-To: <5cae42b20908051415s44fa2dc0h8aabcd34dcce0857@mail.gmail.com> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <5cae42b20908051415s44fa2dc0h8aabcd34dcce0857@mail.gmail.com> Message-ID: <365118370908051427s4a7e4d0fw6cdec56c7fd2d22a@mail.gmail.com> I concur that the globalize stuff is a serious hack and should be removed at some point. However, I don't think 4.0 is the right time to remove it considering the huge impact it will have on 3rd-party products. If removing it doesn't result in a significant performance improvement (and apparently it does not), then I'd suggest we continue to live with it until the "break-everything" 5.0 release. We didn't have a PLIP for this and it would be a major disruption for 3rd party developers and integrators. Perhaps we could find some clever way to deprecate access to the globalized attributes (e.g. make them all lazy lookups and issue a warning on first access)? Alec On Wed, Aug 5, 2009 at 2:15 PM, Hanno Schlichting wrote: > On Wed, Aug 5, 2009 at 10:00 PM, Erik Rose wrote: >> ?* All the globalization in templates is gone now, and Plone's >> ? templates have been updated to not use it. This originated in the >> ? 5.x branch as a speed optimization, but does it deliver? It's >> ? going to break a lot of products. MatthewWilkes will talk to >> ? Hanno about this and see if it really did help performance. The >> ? FWT is concerned about breaking every product if it turns our >> ? we're just replacing one very slow thing with many less-slow >> ? things. > > This change is not only and maybe not even primarily a speed optimization. > > When running performance tests against current Plone 4 for typical > full-fledged pages like a document view, edit screens or folder > contents views, there is hardly any performance difference between > Plone 4.0 and 3.3. Thus there doesn't seem to be an immediate > performance gain for those kind of pages, but neither is there any > increased cost. > > One thing where you should be able to measure a significant difference > is on classic portlets. These used to set up all the globalize stuff > again for the separate expression context of the classic template, > making them quite a bit slower. Executing the globalize hack twice or > even many times was certainly quite a bit of a difference. > > The reasons why I'm very much in favor of removing the globalize hack > are different ones: > > Obviously the way it is done is an utter hack. Walking up stack frames > to inject things into a higher global scope is very evil. > > Second the "globalized" names are today a random set of shortcuts, > which have little to do with the typical need inside templates. They > started out a point where access to a set of tools was essentially the > whole Plone API, but this isn't the case anymore. > > Now they just make it harder to understand template code as there is > no way to find the actual code path from for example the "syntool" > name inside a template to the actual implementation. They obscure > templates for little to no benefit, as most often the real call is a > one-liner itself and context/portal_syndication gives a much better > searchable term. > > Another point is that they make templates rely on execution order of > the whole macros system. They only work when called after the > globalize hack has been executed but not in isolation. This also leads > to problems when trying to move templates into more reusable packages > as it becomes very hard to see the actual dependencies of the > template. What looks like locally defined shortcuts turn out to be "oh > and btw. I need those other ten packages"-type dependencies. It would > have been much harder to understand and disentangle dependencies > between packages on trunk, if those hacked in names still would have > been in place. If we want to make things optional to get people a more > speedy and less memory hungry Plone, having a central place that binds > them all doesn't work. > > And last removing these calls from a centralized place makes both > profiling of what actually contributes to the slowness of Plone much > easier and allows for easier deprecation of some of the so far > globalized names. For example many of the actual performance > improvements on trunk result from changes to the way actions are > looked up. To make these work, all of the "actions, keyed_actions, > user_actions, workflow_actions, folder_actions, global_actions" names > of todays globalize thing need to be deprecated and replaced. Instead > of always having these defined everywhere, they need to be turned into > a pattern where only the viewlet / macro that actually shows the > particular action category also calls and evaluates those actions. For > example hiding the personal bar in the UI today doesn't make a > difference since all the actions in that category are still evaluated > and their conditions checked. Even though nobody will ever show any of > them. > > Maybe I forgot other reasons why this particular hack is considered one ;-) > > Hanno > > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > From optilude+lists at gmail.com Wed Aug 5 23:58:30 2009 From: optilude+lists at gmail.com (Martin Aspeli) Date: Wed Aug 5 23:58:50 2009 Subject: [Framework-Team] Re: Minutes: 8 August 2009 In-Reply-To: <365118370908051427s4a7e4d0fw6cdec56c7fd2d22a@mail.gmail.com> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <5cae42b20908051415s44fa2dc0h8aabcd34dcce0857@mail.gmail.com> <365118370908051427s4a7e4d0fw6cdec56c7fd2d22a@mail.gmail.com> Message-ID: Alec Mitchell wrote: > I concur that the globalize stuff is a serious hack and should be > removed at some point. However, I don't think 4.0 is the right time > to remove it considering the huge impact it will have on 3rd-party > products. If removing it doesn't result in a significant performance > improvement (and apparently it does not), then I'd suggest we continue > to live with it until the "break-everything" 5.0 release. We didn't > have a PLIP for this and it would be a major disruption for 3rd party > developers and integrators. +1 > Perhaps we could find some clever way to deprecate access to the > globalized attributes (e.g. make them all lazy lookups and issue a > warning on first access)? +1 Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book From tseaver at palladion.com Thu Aug 6 01:23:45 2009 From: tseaver at palladion.com (Tres Seaver) Date: Thu Aug 6 01:24:04 2009 Subject: [Framework-Team] Re: Minutes: 8 August 2009 In-Reply-To: <365118370908051427s4a7e4d0fw6cdec56c7fd2d22a@mail.gmail.com> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <5cae42b20908051415s44fa2dc0h8aabcd34dcce0857@mail.gmail.com> <365118370908051427s4a7e4d0fw6cdec56c7fd2d22a@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alec Mitchell wrote: > I concur that the globalize stuff is a serious hack and should be > removed at some point. However, I don't think 4.0 is the right time > to remove it considering the huge impact it will have on 3rd-party > products. If removing it doesn't result in a significant performance > improvement (and apparently it does not), then I'd suggest we continue > to live with it until the "break-everything" 5.0 release. We didn't > have a PLIP for this and it would be a major disruption for 3rd party > developers and integrators. Any 3rd party developers who want to find out whether their templates break without the globals can test them easily: just customize the main template under 3.3 and remove the following line: Any template which breaks without that line present can be trivially fixed by adding 'tal:defines' to pull in the names needed. No need for any black majyk here. > Perhaps we could find some clever way to deprecate access to the > globalized attributes (e.g. make them all lazy lookups and issue a > warning on first access)? There is an example of this pattern in the 'ursine_globals' view on the CMF trunk: http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/browser/ursa.py?&view=markup 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKejCh+gerLs4ltQ4RAmKRAJ0ea+hImFlLqsc1N+YwYmGa2R8czQCeIifb jXSsBCCqIHnikyiytjg9ni8= =p6uU -----END PGP SIGNATURE----- From hanno at hannosch.eu Thu Aug 6 02:17:59 2009 From: hanno at hannosch.eu (Hanno Schlichting) Date: Thu Aug 6 02:23:14 2009 Subject: [Framework-Team] Re: Minutes: 8 August 2009 In-Reply-To: References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <5cae42b20908051415s44fa2dc0h8aabcd34dcce0857@mail.gmail.com> <365118370908051427s4a7e4d0fw6cdec56c7fd2d22a@mail.gmail.com> Message-ID: <5cae42b20908051917t4a4ebb00j600b0740346177e4@mail.gmail.com> On Thu, Aug 6, 2009 at 3:23 AM, Tres Seaver wrote: > Alec Mitchell wrote: >> Perhaps we could find some clever way to deprecate access to the >> globalized attributes (e.g. make them all lazy lookups and issue a >> warning on first access)? > > There is an example of this pattern in the 'ursine_globals' view on the > CMF trunk: > > http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/browser/ursa.py?&view=markup Which doesn't help here. If the Plone version would be of the form "someview_called_globals/utool" it's quite easy to do something on attribute lookup from that "someview_called_globals" object. Unfortunately the Plone version uses setGlobal on each and every attribute of that globalize view. So in the template there's no intermediate object anymore but magically "utool" is available in the scope. This would need some kind of very clever lazy proxy object which would introduce a hook in between the lookup and the actual code. Since the TAL machinery itself checks the scope for availability of names in some ways, that proxy couldn't just defer everything. This also gets somewhat more complex with the two TAL implementations we have now. It might be possible to do this, but its certainly not easy. Hanno From davidglick at onenw.org Thu Aug 6 04:30:54 2009 From: davidglick at onenw.org (David Glick) Date: Thu Aug 6 04:31:33 2009 Subject: (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> Message-ID: On Aug 5, 2009, at 1:45 PM, Alec Mitchell wrote: > On Wed, Aug 5, 2009 at 1:18 PM, David Glick > wrote: >>> * IPublishTraverse is used where ITraverse should be; that's why >>> some >>> linkintegrity tests are failing. >> >> Actually they both need to be used. And that's just a guess -- I >> haven't >> actually looked at this yet. > > It doesn't look like there's any way to override OFS traversal using a > component (other than a view of course). Perhaps we should just be > using the existing custom __getitem__ that's already in > BaseObject/BaseFolder instead of traversal magic. That seems like a decent idea to me, given that we need this to work for publish traversal, OFS traversal, and path expressions in order to avoid regressions. Does anyone know the background or justification for http://dev.plone.org/old/archetypes/changeset/9318 where the switch to an IPublishTraverse adapter first happened? Wichert? Even if we use BaseObject's __getitem__, we probably ought to make the image scale lookup be adapter-based...I know that Andi has had plans to take advantage of the IPublishTraverse adapter in plone.app.imaging to override how scales are found (see http://svn.plone.org/svn/plone/plone.app.imaging/trunk/src/plone/app/imaging/traverse.py -- but this ImageTraverser isn't actually registered anywhere yet). David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidglick@onenw.org 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 From wichert at wiggy.net Thu Aug 6 07:38:37 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Thu Aug 6 07:38:42 2009 Subject: (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> Message-ID: <4A7A887D.3030202@wiggy.net> On 2009-8-6 06:30, David Glick wrote: > Does anyone know the background or justification for > http://dev.plone.org/old/archetypes/changeset/9318 where the switch to > an IPublishTraverse adapter first happened? Wichert? The reasoning behind that is a) we want to get rid of __bobo_traverse__ methods and b) this change transparently exposes all image where the original code only hardcoded exposure of a field with the name 'iage'. I don't quite see what the problem is with that code; can someone explain that? Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From az at zitc.de Thu Aug 6 12:42:48 2009 From: az at zitc.de (Andreas Zeidler) Date: Thu Aug 6 12:43:24 2009 Subject: (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> Message-ID: On Aug 6, 2009, at 6:30 AM, David Glick wrote: > On Aug 5, 2009, at 1:45 PM, Alec Mitchell wrote: >> On Wed, Aug 5, 2009 at 1:18 PM, David Glick >> wrote: >>>> * IPublishTraverse is used where ITraverse should be; that's why >>>> some >>>> linkintegrity tests are failing. >>> >>> Actually they both need to be used. And that's just a guess -- I >>> haven't >>> actually looked at this yet. >> >> It doesn't look like there's any way to override OFS traversal >> using a >> component (other than a view of course). Perhaps we should just be >> using the existing custom __getitem__ that's already in >> BaseObject/BaseFolder instead of traversal magic. > > That seems like a decent idea to me, given that we need this to work > for publish traversal, OFS traversal, and path expressions in order > to avoid regressions. i've just tested linkintegrity in a blob-enabled setup (in order to use the traversal adapter from `plone.app.imaging` in a known to work environment, i.e. plone 3.x) and it turns out that it still has 13 failures ? as opposed to the 25 currently seen in tests against plone 4.0. the remaining 12 failure are very likely due to the "default mime-type issue" (which in turn seems to be caused by the patch in https://bugs.launchpad.net/zope2/+bug/143948 ? thanks to david for investigating, btw). > Does anyone know the background or justification for http://dev.plone.org/old/archetypes/changeset/9318 > where the switch to an IPublishTraverse adapter first happened? > Wichert? since `p.a.blob` currently depends on `p.a.imaging`, which has the same traversal adapter as wichert introduced here, and "image support" will be required for the respective 4.0 plip, this needs to be fixed for linkintegrity to work again anyway. iow, i'll try to look into it during the sprint... > Even if we use BaseObject's __getitem__, we probably ought to make > the image scale lookup be adapter-based...I know that Andi has had > plans to take advantage of the IPublishTraverse adapter in > plone.app.imaging to override how scales are found (see http://svn.plone.org/svn/plone/plone.app.imaging/trunk/src/plone/app/imaging/traverse.py > -- but this ImageTraverser isn't actually registered anywhere yet). those plans have long been carried out and the adapter is registered, in fact ? see http://dev.plone.org/plone/changeset/27627 :) cheers, andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc4 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090806/e5a2b819/PGP.pgp From az at zitc.de Thu Aug 6 12:45:43 2009 From: az at zitc.de (Andreas Zeidler) Date: Thu Aug 6 12:46:14 2009 Subject: [Framework-Team] Re: Minutes: 8 August 2009 In-Reply-To: <5cae42b20908051917t4a4ebb00j600b0740346177e4@mail.gmail.com> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <5cae42b20908051415s44fa2dc0h8aabcd34dcce0857@mail.gmail.com> <365118370908051427s4a7e4d0fw6cdec56c7fd2d22a@mail.gmail.com> <5cae42b20908051917t4a4ebb00j600b0740346177e4@mail.gmail.com> Message-ID: On Aug 6, 2009, at 4:17 AM, Hanno Schlichting wrote: > On Thu, Aug 6, 2009 at 3:23 AM, Tres Seaver > wrote: >> Alec Mitchell wrote: >>> Perhaps we could find some clever way to deprecate access to the >>> globalized attributes (e.g. make them all lazy lookups and issue a >>> warning on first access)? >> >> There is an example of this pattern in the 'ursine_globals' view on >> the >> CMF trunk: >> >> http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/browser/ursa.py?&view=markup > > Which doesn't help here. If the Plone version would be of the form > "someview_called_globals/utool" it's quite easy to do something on > attribute lookup from that "someview_called_globals" object. > Unfortunately the Plone version uses setGlobal on each and every > attribute of that globalize view. So in the template there's no > intermediate object anymore but magically "utool" is available in the > scope. > > This would need some kind of very clever lazy proxy object which would > introduce a hook in between the lookup and the actual code. Since the > TAL machinery itself checks the scope for availability of names in > some ways, that proxy couldn't just defer everything. This also gets > somewhat more complex with the two TAL implementations we have now. It > might be possible to do this, but its certainly not easy. wouldn't it be possible to use @properties here? they could issue the deprecation warning and return the "real global" after `setGlobal` had been used on them... just brainstorming, though, i.e. i might be missing something essential :) andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc4 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090806/ddbf2dcb/PGP.pgp From az at zitc.de Thu Aug 6 12:48:46 2009 From: az at zitc.de (Andreas Zeidler) Date: Thu Aug 6 12:49:18 2009 Subject: (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> Message-ID: <590CFC0E-150D-4ED3-B952-DABEC0FD641A@zitc.de> On Aug 6, 2009, at 2:42 PM, Andreas Zeidler wrote: > On Aug 6, 2009, at 6:30 AM, David Glick wrote: >> On Aug 5, 2009, at 1:45 PM, Alec Mitchell wrote: >>> On Wed, Aug 5, 2009 at 1:18 PM, David Glick >>> wrote: >>>>> * IPublishTraverse is used where ITraverse should be; that's why >>>>> some >>>>> linkintegrity tests are failing. >>>> >>>> Actually they both need to be used. And that's just a guess -- I >>>> haven't >>>> actually looked at this yet. >>> >>> It doesn't look like there's any way to override OFS traversal >>> using a >>> component (other than a view of course). Perhaps we should just be >>> using the existing custom __getitem__ that's already in >>> BaseObject/BaseFolder instead of traversal magic. >> >> That seems like a decent idea to me, given that we need this to >> work for publish traversal, OFS traversal, and path expressions in >> order to avoid regressions. > > i've just tested linkintegrity in a blob-enabled setup (in order to > use the traversal adapter from `plone.app.imaging` in a known to > work environment, i.e. plone 3.x) and it turns out that it still has > 13 failures [...] btw, are there any other reasons/breakages besides the linkintegrity failures? i suppose i could make the latter aware of the traversal adapter, too. do we know of any (important) 3rd-party products that rely on being able to traverse to image scales the old way? > cheers, > > > andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc4 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090806/2e5bbe08/PGP.pgp From davidglick at onenw.org Thu Aug 6 15:47:52 2009 From: davidglick at onenw.org (David Glick) Date: Thu Aug 6 15:48:31 2009 Subject: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> Message-ID: On Aug 6, 2009, at 5:42 AM, Andreas Zeidler wrote: > i've just tested linkintegrity in a blob-enabled setup (in order to > use the traversal adapter from `plone.app.imaging` in a known to > work environment, i.e. plone 3.x) and it turns out that it still has > 13 failures ? as opposed to the 25 currently seen in tests against > plone 4.0. the remaining 12 failure are very likely due to the > "default mime-type issue" (which in turn seems to be caused by the > patch in https://bugs.launchpad.net/zope2/+bug/143948 ? thanks to > david for investigating, btw). Were you using an svn checkout of linkintegrity? I adjusted the tests last night to specify a 'text/html' mimetype where needed, so if you're using an svn checkout then the remaining failures are something else (unless I missed an occurrence or two). Following my changes I was seeing 18 failures for linkintegrity with Plone 4. From the investigating I've done so far, I think there are two main causes for the remaining failures: - linkintegrity's getObjectsFromLinks method uses OFS traversal, which is not aware of IPublishTraverse adapters and therefore does not find image scales ... as I've been discussing here - The linkintegrity tests try to trick the testrunner into not handling the LinkIntegrityNotificationException ... this is no longer working properly in Zope 2.12 for some reason. >> Does anyone know the background or justification for http://dev.plone.org/old/archetypes/changeset/9318 >> where the switch to an IPublishTraverse adapter first happened? >> Wichert? > > since `p.a.blob` currently depends on `p.a.imaging`, which has the > same traversal adapter as wichert introduced here, and "image > support" will be required for the respective 4.0 plip, this needs to > be fixed for linkintegrity to work again anyway. iow, i'll try to > look into it during the sprint... Yep. That would be great. >> Even if we use BaseObject's __getitem__, we probably ought to make >> the image scale lookup be adapter-based...I know that Andi has had >> plans to take advantage of the IPublishTraverse adapter in >> plone.app.imaging to override how scales are found (see http://svn.plone.org/svn/plone/plone.app.imaging/trunk/src/plone/app/imaging/traverse.py >> -- but this ImageTraverser isn't actually registered anywhere yet). > > those plans have long been carried out and the adapter is > registered, in fact ? see http://dev.plone.org/plone/changeset/ > 27627 :) Ah, my bad...I didn't look carefully enough. > btw, are there any other reasons/breakages besides the linkintegrity > failures? i suppose i could make the latter aware of the traversal > adapter, too. do we know of any (important) 3rd-party products that > rely on being able to traverse to image scales the old way? I haven't tested, but I presume that anything which does something like would break. David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidglick@onenw.org 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 From az at zitc.de Thu Aug 6 21:15:11 2009 From: az at zitc.de (Andreas Zeidler) Date: Thu Aug 6 21:15:54 2009 Subject: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> Message-ID: <7A754ACE-CA73-41E6-92EF-C966BD42FA5F@zitc.de> On Aug 6, 2009, at 5:47 PM, David Glick wrote: > On Aug 6, 2009, at 5:42 AM, Andreas Zeidler wrote: >> i've just tested linkintegrity in a blob-enabled setup (in order to >> use the traversal adapter from `plone.app.imaging` in a known to >> work environment, i.e. plone 3.x) and it turns out that it still >> has 13 failures ? as opposed to the 25 currently seen in tests >> against plone 4.0. the remaining 12 failure are very likely due to >> the "default mime-type issue" (which in turn seems to be caused by >> the patch in https://bugs.launchpad.net/zope2/+bug/143948 ? thanks >> to david for investigating, btw). > > Were you using an svn checkout of linkintegrity? yes, i was in fact. but that doesn't matter since i was testing against 3.x anyway. just with `plone.app.imaging` installed, i.e. the (same) traversal adapter enabled. > I adjusted the tests last night to specify a 'text/html' mimetype > where needed, we should not do this. we should really fix the underlying issue instead of adjusting the tests to "cover up"... > so if you're using an svn checkout then the remaining failures are > something else (unless I missed an occurrence or two). Following my > changes I was seeing 18 failures for linkintegrity with Plone 4. hmm, you might have missed a few then. just adding the traversal adapter seems to introduce 13 failures. but 13 or 18, it definitely needs fixing... :) > From the investigating I've done so far, I think there are two main > causes for the remaining failures: > - linkintegrity's getObjectsFromLinks method uses OFS traversal, > which is not aware of IPublishTraverse adapters and therefore does > not find image scales ... as I've been discussing here right, but in this case i'd suggest fixing linkintegrity, since requiring something like image scales to be (aq-wrapped) sub-objects doesn't sound right anyway. > - The linkintegrity tests try to trick the testrunner into not > handling the LinkIntegrityNotificationException ... this is no > longer working properly in Zope 2.12 for some reason. well, it was a bit of a hack anyway. however, i think in one of the quick tests i did earlier setting `>>> browser.handleErrors = False` solved the issue. i've got no idea why it would, but perhaps you wanna give it a try... or i will :) >> those plans have long been carried out and the adapter is >> registered, in fact ? see http://dev.plone.org/plone/changeset/ >> 27627 :) > > Ah, my bad...I didn't look carefully enough. i hid it away ;) >> btw, are there any other reasons/breakages besides the >> linkintegrity failures? i suppose i could make the latter aware of >> the traversal adapter, too. do we know of any (important) 3rd- >> party products that rely on being able to traverse to image scales >> the old way? > > I haven't tested, but I presume that anything which does something > like > tal:replace="structure python:context.tag(scale='thumb')"/> > would break. yes, it would, of course. however, those should be trivial to fix provided we document it properly. so since we'll need to make that change anyway ? or say, we'd really like to ? i'd be in favour of doing it now and avoid adding more magic workarounds to make it work both ways... andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc4 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090806/63739ae4/PGP.pgp From maurits at vanrees.org Thu Aug 6 23:52:13 2009 From: maurits at vanrees.org (Maurits van Rees) Date: Fri Aug 7 00:14:20 2009 Subject: [Framework-Team] Good spot for documentation of ready-for-review plip? Message-ID: <20090806235212.GA4647@ip4da647da.direct-adsl.nl> Hi, I am working on plip 9214 (email logins - not finished yet). I wonder what the best spot is for adding some documentation about this plip (or others plips) with pointers for the framework team. I think most plip authors used to add a README.txt to the branch that had the plip implementation. But the plips are now just config files in the same directory. So where do I put this? - Something like plone-coredev/branches/4.0/plips/doc/plip9214.txt ? - The trac ticket of the plip ? - A mail to the framework list? - Copy/paste to all of the above? -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "Yes, we study economics, got to make the money make some kind of sense." - Geoff Mann From ems174 at psu.edu Fri Aug 7 00:49:38 2009 From: ems174 at psu.edu (Eric Steele) Date: Fri Aug 7 00:50:11 2009 Subject: [Framework-Team] Good spot for documentation of ready-for-review plip? In-Reply-To: <20090806235212.GA4647@ip4da647da.direct-adsl.nl> References: <20090806235212.GA4647@ip4da647da.direct-adsl.nl> Message-ID: Yes, sorry. I'd meant to send out an email detailing this procedure for everyone. I'll be sure to do that shortly. The FWT decided that a readme placed in the 4.0 buildout's plips folder would be preferred. Bonus points for linking to it (or the changeset that adds it) in your PLIP ticket. See http://svn.plone.org/svn/plone/review/plip240-locking-improvements/PLIP_240_README.txt for an example of what sort of readme the FWT would like to see. Eric On Aug 6, 2009, at 7:52 PM, Maurits van Rees wrote: > Hi, > > I am working on plip 9214 (email logins - not finished yet). I wonder > what the best spot is for adding some documentation about this plip > (or others plips) with pointers for the framework team. I think most > plip authors used to add a README.txt to the branch that had the plip > implementation. But the plips are now just config files in the same > directory. So where do I put this? > > - Something like plone-coredev/branches/4.0/plips/doc/plip9214.txt ? > > - The trac ticket of the plip ? > > - A mail to the framework list? > > - Copy/paste to all of the above? > > -- > Maurits van Rees | http://maurits.vanrees.org/ > Work | http://zestsoftware.nl/ > "Yes, we study economics, > got to make the money make some kind of sense." - Geoff Mann > > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team From wichert at wiggy.net Fri Aug 7 10:13:17 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Fri Aug 7 10:13:26 2009 Subject: [Framework-Team] Re: [Collective-checkins] r93885 - in Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS: tests tools In-Reply-To: <4A7BFBBF.4090104@fourdigits.nl> References: <4A7BFA85.7030108@wiggy.net> <4A7BFBBF.4090104@fourdigits.nl> Message-ID: <4A7BFE3D.9080704@wiggy.net> On 8/7/09 12:02 , Ralph Jacobs wrote: > Wichert Akkerman wrote: >> On 8/7/09 09:51 , Ralph Jacobs wrote: >>> Author: ralphjacobs >>> Date: Fri Aug 7 07:51:00 2009 >>> New Revision: 93885 >>> >>> Modified: >>> Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS/tests/test_membershiptool.py >>> >>> Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS/tools/membership.py >>> >>> Log: >>> Simple Implementation of getFullname and added testGetFullName in >>> test_membershiptool >> >> What is the point of the API extension? This should be done through >> the already existing getMemberInfo imho. >> >> Wichert. > > Hi Wichert, > > We are working on PLIP ticket #9305, see: > https://dev.plone.org/plone/report/24 > and http://lists.plone.org/pipermail/framework-team/2009-July/003071.html I understand that you are implementing a PLIP, but I just want to point out that there is a long existing API with proper permission handling which returns member information, including the full name: the getMemerInfo call. That method is just as expensive as your new method, so performance is not a valid argument. I'm afraid I also don't buy the lookup mechanism mentioned in the PDF: you are essentialy creating a persistent cache system, which means that suddenly page views can trigger ZODB writes, which is very bad for high performance sites. It also will miss all user changes created directly in external user sources such as LDAP, AD and SQL databases, leading to incorrect and possibly correct behaviour. If there is a performance problem, which has not been proven yet, it should imho be solved at a different point. All the required PAS methods are already ZCacheable, so that is not expensive. The single object wakeup to get the users member data is also not that bad, and I would be very surprised if that shows up in a real world profile. Wichert. From wichert at wiggy.net Fri Aug 7 10:16:41 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Fri Aug 7 10:16:45 2009 Subject: [Framework-Team] Re: [Collective-checkins] r93885 - in Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS: tests tools In-Reply-To: <4A7BFE3D.9080704@wiggy.net> References: <4A7BFA85.7030108@wiggy.net> <4A7BFBBF.4090104@fourdigits.nl> <4A7BFE3D.9080704@wiggy.net> Message-ID: <4A7BFF09.9070405@wiggy.net> On 8/7/09 12:13 , Wichert Akkerman wrote: > > I'm afraid I also don't buy the lookup mechanism mentioned in the PDF: > you are essentialy creating a persistent cache system, which means that > suddenly page views can trigger ZODB writes, which is very bad for high > performance sites. It also will miss all user changes created directly > in external user sources such as LDAP, AD and SQL databases, leading to > incorrect and possibly correct behaviour. That should be 'possibly confusing' Wichert. From wichert at wiggy.net Fri Aug 7 10:21:27 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Fri Aug 7 10:21:32 2009 Subject: [Framework-Team] Re: [Collective-checkins] r93885 - in Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS: tests tools In-Reply-To: <4A7BFFDB.60400@fourdigits.nl> References: <4A7BFA85.7030108@wiggy.net> <4A7BFBBF.4090104@fourdigits.nl> <4A7BFE3D.9080704@wiggy.net> <4A7BFF09.9070405@wiggy.net> <4A7BFFDB.60400@fourdigits.nl> Message-ID: <4A7C0027.3040202@wiggy.net> On 8/7/09 12:20 , Ralph Jacobs wrote: > Wichert Akkerman wrote: >> On 8/7/09 12:13 , Wichert Akkerman wrote: >>> >>> I'm afraid I also don't buy the lookup mechanism mentioned in the PDF: >>> you are essentialy creating a persistent cache system, which means that >>> suddenly page views can trigger ZODB writes, which is very bad for high >>> performance sites. It also will miss all user changes created directly >>> in external user sources such as LDAP, AD and SQL databases, leading to >>> incorrect and possibly correct behaviour. >> >> That should be 'possibly confusing' >> >> Wichert. >> > Hi Wichert, > > This all has been discussed in the PLIP proposal, so please contact the > framework team for that. That's why I added a cc to the framework team list and added my comments to the trac ticket :) Wichert. From wichert at wiggy.net Fri Aug 7 10:28:41 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Fri Aug 7 10:28:46 2009 Subject: [Framework-Team] Re: [Collective-checkins] r93885 - in Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS: tests tools In-Reply-To: <4A7BFFDB.60400@fourdigits.nl> References: <4A7BFA85.7030108@wiggy.net> <4A7BFBBF.4090104@fourdigits.nl> <4A7BFE3D.9080704@wiggy.net> <4A7BFF09.9070405@wiggy.net> <4A7BFFDB.60400@fourdigits.nl> Message-ID: <4A7C01D9.7040403@wiggy.net> On 8/7/09 12:20 , Ralph Jacobs wrote: > Wichert Akkerman wrote: >> On 8/7/09 12:13 , Wichert Akkerman wrote: >>> >>> I'm afraid I also don't buy the lookup mechanism mentioned in the PDF: >>> you are essentialy creating a persistent cache system, which means that >>> suddenly page views can trigger ZODB writes, which is very bad for high >>> performance sites. It also will miss all user changes created directly >>> in external user sources such as LDAP, AD and SQL databases, leading to >>> incorrect and possibly correct behaviour. >> >> That should be 'possibly confusing' >> >> Wichert. >> > Hi Wichert, > > This all has been discussed in the PLIP proposal, so please contact the > framework team for that. I just checked the history of the trac ticket since I was surprised the framework missed this. The framework team has only voted on the idea of using a users full name instead of the userid in the Plone user interface. The implementation proposal was added three weeks, and will be taken into account in the next review round when the PLIP implementations will be reviewed. So please consider this a very early (and very unofficial since I am not a framework team member) review comment: I do like the idea to use a users full name, but I do see some problems with the current implementation strategy that should be addressed. Wichert. From az at zitc.de Fri Aug 7 10:49:33 2009 From: az at zitc.de (Andreas Zeidler) Date: Fri Aug 7 10:50:21 2009 Subject: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: <7A754ACE-CA73-41E6-92EF-C966BD42FA5F@zitc.de> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> <7A754ACE-CA73-41E6-92EF-C966BD42FA5F@zitc.de> Message-ID: <5EBE4EAF-23FD-4A22-9A49-05571BEDC4E5@zitc.de> On Aug 6, 2009, at 11:15 PM, Andreas Zeidler wrote: > On Aug 6, 2009, at 5:47 PM, David Glick wrote: >> On Aug 6, 2009, at 5:42 AM, Andreas Zeidler wrote: >>> i've just tested linkintegrity in a blob-enabled setup (in order >>> to use the traversal adapter from `plone.app.imaging` in a known >>> to work environment, i.e. plone 3.x) and it turns out that it >>> still has 13 failures ? as opposed to the 25 currently seen in >>> tests against plone 4.0. the remaining 12 failure are very likely >>> due to the "default mime-type issue" (which in turn seems to be >>> caused by the patch in https://bugs.launchpad.net/zope2/+bug/ >>> 143948 ? thanks to david for investigating, btw). >> >> [...] >> >> I adjusted the tests last night to specify a 'text/html' mimetype >> where needed, > > we should not do this. we should really fix the underlying issue > instead of adjusting the tests to "cover up"... ok, i've used the plane ride this morning to have a look and the `content_types` patch makes sense, of course. i've reverted your fixes nevertheless (being picky as i am :)) and added a helper "mutator" to set proper html markup instead. i guess i should have done that long time ago as the test are much more readable now ? imho... :) >> so if you're using an svn checkout then the remaining failures are >> something else (unless I missed an occurrence or two). Following >> my changes I was seeing 18 failures for linkintegrity with Plone 4. > > hmm, you might have missed a few then. just adding the traversal > adapter seems to introduce 13 failures. but 13 or 18, it definitely > needs fixing... :) iirc you didn't miss any of the mime-type related failures ? the remaining stuff was due to the traversal adapter and some other test setup issues. >> From the investigating I've done so far, I think there are two main >> causes for the remaining failures: >> - linkintegrity's getObjectsFromLinks method uses OFS traversal, >> which is not aware of IPublishTraverse adapters and therefore does >> not find image scales ... as I've been discussing here > > right, but in this case i'd suggest fixing linkintegrity, since > requiring something like image scales to be (aq-wrapped) sub-objects > doesn't sound right anyway. i've extended the code to be aware of traversal adapters, and we're back to zero failures now. >> - The linkintegrity tests try to trick the testrunner into not >> handling the LinkIntegrityNotificationException ... this is no >> longer working properly in Zope 2.12 for some reason. > > well, it was a bit of a hack anyway. however, i think in one of the > quick tests i did earlier setting `>>> browser.handleErrors = False` > solved the issue. i've got no idea why it would, but perhaps you > wanna give it a try... or i will :) this indeed made some ? i think 4 or so ? tests pass again (see http://dev.plone.org/plone/changeset/28458) . i'm not quite sure what's going on here, though. >> I haven't tested, but I presume that anything which does something >> like >> > tal:replace="structure python:context.tag(scale='thumb')"/> >> would break. > > yes, it would, of course. however, those should be trivial to fix > provided we document it properly. so since we'll need to make that > change anyway ? or say, we'd really like to ? i'd be in favour of > doing it now and avoid adding more magic workarounds to make it work > both ways... hmm, being the only remaining issue now i was just wondering if none of the plone templates are actually using this pattern. `plone.app.imaging` does have some browsertests, and i didn't modify any of the templates. we should definitely look into this again, though... > andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc4 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090807/0bc0e59f/PGP.pgp From apm13 at columbia.edu Fri Aug 7 13:47:46 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Fri Aug 7 13:47:54 2009 Subject: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> Message-ID: <365118370908070647x1f7e9bf8s290782ec29886cd9@mail.gmail.com> On Thu, Aug 6, 2009 at 8:47 AM, David Glick wrote: > On Aug 6, 2009, at 5:42 AM, Andreas Zeidler wrote: >> >> i've just tested linkintegrity in a blob-enabled setup (in order to use >> the traversal adapter from `plone.app.imaging` in a known to work >> environment, i.e. plone 3.x) and it turns out that it still has 13 failures >> ? as opposed to the 25 currently seen in tests against plone 4.0. ?the >> remaining 12 failure are very likely due to the "default mime-type issue" >> (which in turn seems to be caused by the patch in >> https://bugs.launchpad.net/zope2/+bug/143948 ? thanks to david for >> investigating, btw). > > Were you using an svn checkout of linkintegrity? ?I adjusted the tests last > night to specify a 'text/html' mimetype where needed, so if you're using an > svn checkout then the remaining failures are something else (unless I missed > an occurrence or two). ?Following my changes I was seeing 18 failures for > linkintegrity with Plone 4. > > From the investigating I've done so far, I think there are two main causes > for the remaining failures: > - linkintegrity's getObjectsFromLinks method uses OFS traversal, which is > not aware of IPublishTraverse adapters and therefore does not find image > scales ... as I've been discussing here > - The linkintegrity tests try to trick the testrunner into not handling the > LinkIntegrityNotificationException ... this is no longer working properly in > Zope 2.12 for some reason. > >>> Does anyone know the background or justification for >>> http://dev.plone.org/old/archetypes/changeset/9318?where the switch to an >>> IPublishTraverse adapter first happened? ?Wichert? >> >> since `p.a.blob` currently depends on `p.a.imaging`, which has the same >> traversal adapter as wichert introduced here, and "image support" will be >> required for the respective 4.0 plip, this needs to be fixed for >> linkintegrity to work again anyway. ?iow, i'll try to look into it during >> the sprint... > > Yep. ?That would be great. > >>> Even if we use BaseObject's __getitem__, we probably ought to make the >>> image scale lookup be adapter-based...I know that Andi has had plans to take >>> advantage of the IPublishTraverse adapter in plone.app.imaging to override >>> how scales are found (see >>> http://svn.plone.org/svn/plone/plone.app.imaging/trunk/src/plone/app/imaging/traverse.py?-- >>> but this ImageTraverser isn't actually registered anywhere yet). >> >> those plans have long been carried out and the adapter is registered, in >> fact ? see http://dev.plone.org/plone/changeset/27627 :) > > > Ah, my bad...I didn't look carefully enough. > >> btw, are there any other reasons/breakages besides the linkintegrity >> failures? ?i suppose i could make the latter aware of the traversal adapter, >> too. ?do we know of any (important) 3rd-party products that rely on being >> able to traverse to image scales the old way? > > I haven't tested, but I presume that anything which does something like > > would break. Though linkintegrity may be working now, I think the code above would still fail. I'd guess there's a lot of code in the wild that uses path expressions to access image scales by name, and we're breaking all that code unless we fix this for the general case. OTOH, we could simply declare that we're OK with breaking backwards compatibility here if we have consensus that this is worthwhile. Perhaps we should vote on this or discuss on the next call. Alec From apm13 at columbia.edu Fri Aug 7 14:00:09 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Fri Aug 7 14:00:13 2009 Subject: [Framework-Team] Re: [Collective-checkins] r93885 - in Products.PlonePAS/branches/plip9305-fullname/Products/PlonePAS: tests tools In-Reply-To: <4A7C01D9.7040403@wiggy.net> References: <4A7BFA85.7030108@wiggy.net> <4A7BFBBF.4090104@fourdigits.nl> <4A7BFE3D.9080704@wiggy.net> <4A7BFF09.9070405@wiggy.net> <4A7BFFDB.60400@fourdigits.nl> <4A7C01D9.7040403@wiggy.net> Message-ID: <365118370908070700o11fea322h89e93c0d39f11323@mail.gmail.com> On Fri, Aug 7, 2009 at 3:28 AM, Wichert Akkerman wrote: > On 8/7/09 12:20 , Ralph Jacobs wrote: >> >> Wichert Akkerman wrote: >>> >>> On 8/7/09 12:13 , Wichert Akkerman wrote: >>>> >>>> I'm afraid I also don't buy the lookup mechanism mentioned in the PDF: >>>> you are essentialy creating a persistent cache system, which means that >>>> suddenly page views can trigger ZODB writes, which is very bad for high >>>> performance sites. It also will miss all user changes created directly >>>> in external user sources such as LDAP, AD and SQL databases, leading to >>>> incorrect and possibly correct behaviour. >>> >>> That should be 'possibly confusing' >>> >>> Wichert. >>> >> Hi Wichert, >> >> This all has been discussed in the PLIP proposal, so please contact the >> framework team for that. > > I just checked the history of the trac ticket since I was surprised the > framework missed this. The framework team has only voted on the idea of > using a users full name instead of the userid in the Plone user interface. > The implementation proposal was added three weeks, and will be taken into > account in the next review round when the PLIP implementations will be > reviewed. So please consider this a very early (and very unofficial since I > am not a framework team member) review comment: I do like the idea to use a > users full name, but I do see some problems with the current implementation > strategy that should be addressed. Please listen to Wichert's advice here, a persistent cache of user data will not be considered acceptable. Make an uncached implementation and benchmark some listings vs. stock Plone. Include those benchmarks as part of the PLIP documentation. If there is a performance issue, then it can be addressed during review or in discussions with the framework team. Using the existing cacheability of the PAS calls could be advantageous (though it is likely to lead to out-of-sync ZEO client caches). Alternatively, plone.memoize could be used to provide a single request cache or a ramcache with a short, configrable expiration time. In any case, it's too early in the implementation to be adding caches without benchmarks. Alec From optilude+lists at gmail.com Sun Aug 9 16:46:07 2009 From: optilude+lists at gmail.com (Martin Aspeli) Date: Sun Aug 9 16:46:29 2009 Subject: [Framework-Team] Three PLIPs ready for review Message-ID: Hi folks, Just a quick note: I'm now done with the implementations of: https://dev.plone.org/plone/ticket/9259 (group dashboards) https://dev.plone.org/plone/ticket/9263 (sharing roles GS syntax) https://dev.plone.org/plone/ticket/9264 (add_view_expr support) I'll be on holiday from August 15th-22nd, but hopefully you should be able to review without too much drama. There are PLIP buildout configs + notes for all, and the tickets include references to all relevant changesets. Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book From az at zitc.de Mon Aug 10 09:33:57 2009 From: az at zitc.de (Andreas Zeidler) Date: Mon Aug 10 09:34:29 2009 Subject: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: <365118370908070647x1f7e9bf8s290782ec29886cd9@mail.gmail.com> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> <365118370908070647x1f7e9bf8s290782ec29886cd9@mail.gmail.com> Message-ID: <95B8892A-996C-4ECD-9923-00C7D12AE283@zitc.de> On Aug 7, 2009, at 3:47 PM, Alec Mitchell wrote: > On Thu, Aug 6, 2009 at 8:47 AM, David Glick > wrote: >> I haven't tested, but I presume that anything which does something >> like >> > tal:replace="structure >> python:context.tag(scale='thumb')"/> >> would break. > > Though linkintegrity may be working now, I think the code above would > still fail. I'd guess there's a lot of code in the wild that uses > path expressions to access image scales by name, and we're breaking > all that code unless we fix this for the general case. yes, like said before, we should check if it does (and most likely it will). > OTOH, we could > simply declare that we're OK with breaking backwards compatibility > here if we have consensus that this is worthwhile. Perhaps we should > vote on this or discuss on the next call. please do. otoh, if we don't want to break it, we should at least deprecate the old way and then drop it in 5.0, or perhaps even in something like 4.2. andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc4 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090810/8139bd93/PGP.pgp From wichert at wiggy.net Mon Aug 10 09:36:46 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon Aug 10 09:37:02 2009 Subject: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: <95B8892A-996C-4ECD-9923-00C7D12AE283@zitc.de> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> <365118370908070647x1f7e9bf8s290782ec29886cd9@mail.gmail.com> <95B8892A-996C-4ECD-9923-00C7D12AE283@zitc.de> Message-ID: <4A7FEA2E.3080101@wiggy.net> On 8/10/09 11:33 , Andreas Zeidler wrote: > On Aug 7, 2009, at 3:47 PM, Alec Mitchell wrote: >> OTOH, we could >> simply declare that we're OK with breaking backwards compatibility >> here if we have consensus that this is worthwhile. Perhaps we should >> vote on this or discuss on the next call. > > please do. otoh, if we don't want to break it, we should at least > deprecate the old way and then drop it in 5.0, or perhaps even in > something like 4.2. 4.x should be like 3.x, which means you can not drop something in 4.2. You can deprecate in 4.2 though. I'm not sure if you mean the first or the latter here. Wichert. From az at zitc.de Mon Aug 10 20:05:27 2009 From: az at zitc.de (Andreas Zeidler) Date: Mon Aug 10 20:06:14 2009 Subject: Image scale traversal (Was Re: [Framework-Team] Minutes: 8 August 2009) In-Reply-To: <4A7FEA2E.3080101@wiggy.net> References: <9FDF130C-1412-40B6-9D5A-7A8E8612F174@grinchcentral.com> <7E7C7B63-E88E-4587-B39E-F7858C577FA3@onenw.org> <365118370908051345j3eec985se105d31f686019e@mail.gmail.com> <365118370908070647x1f7e9bf8s290782ec29886cd9@mail.gmail.com> <95B8892A-996C-4ECD-9923-00C7D12AE283@zitc.de> <4A7FEA2E.3080101@wiggy.net> Message-ID: <13FE89D1-1878-46F5-B260-641D6672B8B2@zitc.de> On Aug 10, 2009, at 11:36 AM, Wichert Akkerman wrote: > On 8/10/09 11:33 , Andreas Zeidler wrote: >> On Aug 7, 2009, at 3:47 PM, Alec Mitchell wrote: >>> OTOH, we could >>> simply declare that we're OK with breaking backwards compatibility >>> here if we have consensus that this is worthwhile. Perhaps we should >>> vote on this or discuss on the next call. >> >> please do. otoh, if we don't want to break it, we should at least >> deprecate the old way and then drop it in 5.0, or perhaps even in >> something like 4.2. > > 4.x should be like 3.x, which means you can not drop something in > 4.2. You can deprecate in 4.2 though. I'm not sure if you mean the > first or the latter here. i actually meant the first, but you're right. so we should either make the change for 4.0, or else we'll have to wait until 5.0. i'd be in favour of the first option... :) andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc5 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090810/3c782482/PGP.pgp From ems174 at psu.edu Tue Aug 11 12:33:53 2009 From: ems174 at psu.edu (Eric Steele) Date: Tue Aug 11 12:34:07 2009 Subject: [Framework-Team] PLIPs ready for review Message-ID: <6E000E73-9F60-48F3-ADD6-6EAC6A607201@psu.edu> FWT, We have 3 PLIPs that are ready for review with quite a few more not far behind. https://dev.plone.org/plone/ticket/9259 https://dev.plone.org/plone/ticket/9263 https://dev.plone.org/plone/ticket/9264 I'll be keeping our spreadsheet (http://spreadsheets.google.com/ccc?key=rR4UAIObeTZtdUExfYophHw ) updated to show PLIP status (in the "Implementation Reviewers" section). We'll need 1-2 people to review each of these. I've not seen any code or comments from Carsten Senger, Ricardo Alves, and of course, Mr. Limi. Does anyone know of their status? Eric From roel at fourdigits.nl Tue Aug 11 15:00:02 2009 From: roel at fourdigits.nl (Roel Bruggink) Date: Tue Aug 11 15:00:31 2009 Subject: [Framework-Team] PLIPS ready for review: #9272 and #9305 Message-ID: <4A818772.5090600@fourdigits.nl> These PLIPs are ready for review: Exposing Dublin Core properties https://dev.plone.org/plone/ticket/9272 Use real names instead of usernames https://dev.plone.org/plone/ticket/9305 -- Roel Bruggink http://www.fourdigits.nl/mensen/roel-bruggink Four Digits BV http://www.fourdigits.nl Willemsplein 44, 6811 KD, Arnhem tel: +31(0)26 4422700 fax: +31(0)84 2206117 KVK 091621370000 BTW 8161.22.234.B01 -------------- next part -------------- A non-text attachment was scrubbed... Name: roel.vcf Type: text/x-vcard Size: 295 bytes Desc: not available Url : http://lists.plone.org/pipermail/framework-team/attachments/20090811/6839f72f/roel.vcf From rob at fourdigits.nl Tue Aug 11 16:57:34 2009 From: rob at fourdigits.nl (Rob Gietema) Date: Tue Aug 11 16:58:01 2009 Subject: [Framework-Team] PLIP #9249 ready for review Message-ID: <53479e250908110957m472dce59x4c0312cc86c587b5@mail.gmail.com> This PLIP is ready for review: Add TinyMCE as the default visual editor https://dev.plone.org/plone/ticket/9249 --Rob Gietema http://blog.fourdigits.nl/robgietema Four Digits http://www.fourdigits.nl Willemsplein 44, 6811 KD, Arnhem, The Netherlands phone: +31(0)26 4422700 fax: +31(0)84 2206117 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20090811/4ed4f7ab/attachment.htm From itconsense at gmail.com Wed Aug 12 06:59:57 2009 From: itconsense at gmail.com (Tom Gross) Date: Wed Aug 12 07:05:11 2009 Subject: [Framework-Team] PLIP #9258 ready for review Message-ID: This PLIP is ready for review: Replace Products.ATReferenceBrowserWidget with archetypes.referencebrowserwidget https://dev.plone.org/old/plone/ticket/9258 -Tom From tseaver at palladion.com Thu Aug 13 03:12:18 2009 From: tseaver at palladion.com (Tres Seaver) Date: Thu Aug 13 03:15:12 2009 Subject: [Framework-Team] Re: MailHost Improvements In-Reply-To: References: Message-ID: <4A838492.1080502@palladion.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alec Mitchell wrote: > Hello, > > I've been working on making Plone use the standard Zope MailHost in place > of the custom Products.SecureMailHost we've been using since Plone 2.1 > (See: http://dev.plone.org/plone/ticket/8814). During this process I've > run into a couple bugs in the MailHost implementation and I believe it is > missing some essential functionality. > > The most significant issue is that if you call send() with a messageText > containing just the message body, and that body has a ':' in it (e.g. a > url) the body will be treated as a header and you'll send a nonsense > message. The current implementation of send() also puts a fairly large > burden on developers who want to generate simple, correctly encoded > messages. Finally, send() relies heavily on the long deprecated 'rfc822' > and 'mimetools' modules which have been removed from Python 3.0. > > I've attached a patch that updates MailHost to use the 'email' module for > parsing and generating messages. In addition to fixing the issues that I > ran across, and maintaining compatibility, it provides a number of new > features: > > * send and sendTemplate accept an optional charset argument. Using this > will set the content-type charset, as well as trigger appropriate encoding > if needed. > > * send and sendTemplate accept an optional msg_type argument which will > set the content type header for the message. > > * The messageText, mfrom, mto, and subject arguments may now be unicode or > encoded non-ascii strings, provided a charset is given. Any unicode input > will be automatically encoded to the provided charset (or the default > charset). Headers will be further encoded in compliance with rfc2822. > The message body will be further encoded using a transfer encoding > determined by the email.Charset registry (e.g. 7bit for us-ascii, > quoted-printable for utf-8 and iso8859, base64 for most other encodings). > > * The messageText argument now accepts email.Message.Message objects > directly. > > I'm attaching a patch that includes these changes as well as tests for all > new functionality. I hope to integrate these changes into Zope 2.12 > before final release, but would like to hear the opinions of Zope > developers before committing. Though these are fairly significant > changes, I believe they provide very useful functionality as well as at > least one critical fix, while maintaining 100% compatibility. +1 for the approach in general (I haven't looked at the patch in detail). Assuming all tests pass, and that you have a test exercising the ':' bug you describe, I would just commit it on the trunk (I think such a change should be in the upcoming 2.12 beta). 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKg4SS+gerLs4ltQ4RAgOuAJ0W2CNRCDQglY75s0HVKFnChOwbnwCfSEmu ph+wxAWDwjG3J8xZV1Cr6+U= =tZEF -----END PGP SIGNATURE----- From lists at zopyx.com Thu Aug 13 04:42:39 2009 From: lists at zopyx.com (Andreas Jung) Date: Thu Aug 13 04:47:09 2009 Subject: [Framework-Team] Re: [Zope-dev] MailHost Improvements In-Reply-To: References: Message-ID: <4A8399BF.8070909@zopyx.com> On 13.08.09 01:03, Alec Mitchell wrote: > Hello, > > I've been working on making Plone use the standard Zope MailHost in > place of the custom Products.SecureMailHost we've been using since > Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). During this > process I've run into a couple bugs in the MailHost implementation and > I believe it is missing some essential functionality. > > The most significant issue is that if you call send() with a > messageText containing just the message body, and that body has a ':' > in it (e.g. a url) the body will be treated as a header and you'll > send a nonsense message. The current implementation of send() also > puts a fairly large burden on developers who want to generate simple, > correctly encoded messages. Finally, send() relies heavily on the > long deprecated 'rfc822' and 'mimetools' modules which have been > removed from Python 3.0. > > I've attached a patch that updates MailHost to use the 'email' module > for parsing and generating messages. In addition to fixing the issues > that I ran across, and maintaining compatibility, it provides a number > of new features: > > * send and sendTemplate accept an optional charset argument. Using > this will set the content-type charset, as well as trigger appropriate > encoding if needed. > > * send and sendTemplate accept an optional msg_type argument which > will set the content type header for the message. > > * The messageText, mfrom, mto, and subject arguments may now be > unicode or encoded non-ascii strings, provided a charset is given. > Any unicode input will be automatically encoded to the provided > charset (or the default charset). Headers will be further encoded in > compliance with rfc2822. The message body will be further encoded > using a transfer encoding determined by the email.Charset registry > (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, > base64 for most other encodings). > > * The messageText argument now accepts email.Message.Message objects > directly. > > I'm attaching a patch that includes these changes as well as tests for > all new functionality. I hope to integrate these changes into Zope > 2.12 before final release, but would like to hear the opinions of Zope > developers before committing. Though these are fairly significant > changes, I believe they provide very useful functionality as well as > at least one critical fix, while maintaining 100% compatibility. This comes very, very late. We are pretty close to a release. Please put the changes on the trunk only. We will check after my vacation if we can move it into the 2.12 beta. Andreas -------------- 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/20090813/0c2d59a6/lists.vcf From psucorp at grinchcentral.com Thu Aug 13 17:44:36 2009 From: psucorp at grinchcentral.com (Erik Rose) Date: Thu Aug 13 17:44:47 2009 Subject: [Framework-Team] Minutes: 12 August 2009 Message-ID: <2BBEC7FE-6AE3-4F40-84CF-FA11899CC5EC@grinchcentral.com> Highlights from the meeting -------------------------------------- * We'll include the well-formed-XHTML PLIP even if it's partly done. * Finished PLIPs are marked at http://spreadsheets.google.com/ccc?key=rR4UAIObeTZtdUExfYophHw on the Implementation Reviewers sheet by a green color in the row background. * All the Plone tests now pass (when run in known-to-be-compatible groups by a script Hanno wrote). To do -------------------------------------- * PLIP implementation deadline is Sunday the 16th. Cheers, Erik Rose From limi at plone.org Thu Aug 13 20:16:06 2009 From: limi at plone.org (Alexander Limi) Date: Thu Aug 13 20:16:35 2009 Subject: [Board] Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor In-Reply-To: <5af21ed10907282301g115dc362i5d90540a7306d52@mail.gmail.com> References: <53479e250907270438m6d2c7e9fl842624df8a362296@mail.gmail.com> <4A6DEDAE.5020709@wiggy.net> <878wia3rb2.fsf@transitory.lefae.org> <365118370907271301v6f7d6ea3hbfb16d78e5875e8d@mail.gmail.com> <5E9659FF-E077-4BD7-A1B6-E641A32AF643@jarn.com> <4A6E9A2E.4020804@wiggy.net> <5ACD15BF-FBE7-40BC-A9F4-5623D1B0B3CA@jarn.com> <5af21ed10907282301g115dc362i5d90540a7306d52@mail.gmail.com> Message-ID: 2009/7/29 Martin Aspeli > 2009/7/29 Jon Stahl : > > > So, my question is: what qualifies as "explicit" agreement? Does it > > have to be "on the permanent record" in some manner? > > In our business, an email that you keep tends to be enough. I would: > > - Ask the relevant people by email > - Ask them to reply by email giving explicit consent > - Store those emails "forever" > - Make a note in a CONTRIBUTORS.txt or similar that these people > consented on a particular date > > If that's ever in dispute, you can go back to those emails. > > I don't see a reason for any kind of "wet signature" so long as > they've signed the contributor agreement. We're not *trying* to be > difficult. :) > +1. One thing that SFLC taught us is that any lawyer will always advice you to have their name signed in blood etc, to make *really* sure that nothing goes wrong. In practice, as long as you can show reasonable intent (and an email should be plenty, if there's forgery going on, that's a different issue), so I think this should be good enough. Keeping the dates in a text file is also convenient. FWIW, Mozilla runs their entire project without a contributor agreement ? so we are already way ahead of what most large open source projects do on this front. :) ? Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20090813/27e8363a/attachment.htm From wichert at wiggy.net Thu Aug 13 20:18:17 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Thu Aug 13 20:18:17 2009 Subject: [Board] Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor In-Reply-To: References: <53479e250907270438m6d2c7e9fl842624df8a362296@mail.gmail.com> <4A6DEDAE.5020709@wiggy.net> <878wia3rb2.fsf@transitory.lefae.org> <365118370907271301v6f7d6ea3hbfb16d78e5875e8d@mail.gmail.com> <5E9659FF-E077-4BD7-A1B6-E641A32AF643@jarn.com> <4A6E9A2E.4020804@wiggy.net> <5ACD15BF-FBE7-40BC-A9F4-5623D1B0B3CA@jarn.com> <5af21ed10907282301g115dc362i5d90540a7306d52@mail.gmail.com> Message-ID: <4A847509.6000306@wiggy.net> On 2009-8-13 22:16, Alexander Limi wrote: > FWIW, Mozilla runs their entire project without a contributor agreement > ? so we are already way ahead of what most large open source projects do > on this front. :) Or way behind when shit hits your fan. Those agreements exists for good reasons. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From apm13 at columbia.edu Fri Aug 14 04:22:07 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Fri Aug 14 04:22:36 2009 Subject: [Framework-Team] Re: [Zope-dev] MailHost Improvements In-Reply-To: <4A8399BF.8070909@zopyx.com> References: <4A8399BF.8070909@zopyx.com> Message-ID: <365118370908132122m211290dej29de6aaf3ed3105f@mail.gmail.com> On Wed, Aug 12, 2009 at 9:42 PM, Andreas Jung wrote: > On 13.08.09 01:03, Alec Mitchell wrote: >> Hello, >> >> I've been working on making Plone use the standard Zope MailHost ?in >> place of the custom Products.SecureMailHost we've been using since >> Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). ?During this >> process I've run into a couple bugs in the MailHost implementation and >> I believe it is missing some essential functionality. >> >> The most significant issue is that if you call send() with a >> messageText containing just the message body, and that body has a ':' >> in it (e.g. a url) the body will be treated as a header and you'll >> send a nonsense message. ?The current implementation of send() also >> puts a fairly large burden on developers who want to generate simple, >> correctly encoded messages. ?Finally, send() relies heavily on the >> long deprecated 'rfc822' and 'mimetools' modules which have been >> removed from Python 3.0. >> >> I've attached a patch that updates MailHost to use the 'email' module >> for parsing and generating messages. ?In addition to fixing the issues >> that I ran across, and maintaining compatibility, it provides a number >> of new features: >> >> * send and sendTemplate accept an optional charset argument. ?Using >> this will set the content-type charset, as well as trigger appropriate >> encoding if needed. >> >> * send and sendTemplate accept an optional msg_type argument which >> will set the content type header for the message. >> >> * The messageText, mfrom, mto, and subject arguments may now be >> unicode or encoded non-ascii strings, provided a charset is given. >> Any unicode input will be automatically encoded to the provided >> charset (or the default charset). ?Headers will be further encoded in >> compliance with rfc2822. ?The message body will be further encoded >> using a transfer encoding determined by the email.Charset registry >> (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, >> base64 for most other encodings). >> >> * The messageText argument now accepts email.Message.Message objects >> directly. >> >> I'm attaching a patch that includes these changes as well as tests for >> all new functionality. ?I hope to integrate these changes into Zope >> 2.12 before final release, but would like to hear the opinions of Zope >> developers before committing. ?Though these are fairly significant >> changes, I believe they provide very useful functionality as well as >> at least one critical fix, while maintaining 100% compatibility. > > This comes very, very late. We are pretty close to a release. Please put > the changes on the trunk only. > We will check after my vacation if we can move it into the 2.12 beta. I've put my latest changes on Zope trunk. All the existing tests pass (with a couple essentially cosmetic modifications in the MailHost tests), and there are 14 new tests which verify both existing and new functionality, as well as the fixed bugs. The new behavior should be identical to the existing behavior when the new charset and msg_type parameters aren't used, with the following exceptions: 1) Passing a message body containing a ':' no longer produces a nonsense email. 2) Providing unicode strings for the text or headers no longer results in a garbage message (it may produce a UnicodeEncodeError though). 3) 8bit (encoded) strings provided as headers will be converted to 7bit, using encoding determined in messageText headers or the default encoding. It would be very helpful to have these changes in Zope 2.12; otherwise, Plone 4.0 will be stuck with our unmaintained SecureMailHost product for yet another release in order to provide equivalent functionality. Moving to a standard Zope MailHost would be a big benefit for Plone, and all Zope users will benefit from the ability to easily send properly formed non-ASCII messages. Alec P.S. Andreas, if there's an address where I can send some nice wine to help facilitate the merge into 2.12, let me know ;-) From jens at dataflake.org Fri Aug 14 06:45:40 2009 From: jens at dataflake.org (Jens Vagelpohl) Date: Fri Aug 14 07:13:56 2009 Subject: [Framework-Team] Re: [Zope-dev] MailHost Improvements In-Reply-To: <365118370908132122m211290dej29de6aaf3ed3105f@mail.gmail.com> References: <4A8399BF.8070909@zopyx.com> <365118370908132122m211290dej29de6aaf3ed3105f@mail.gmail.com> Message-ID: <2FE681A9-623A-4BAB-81C4-7E3FB15E38AA@dataflake.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 14, 2009, at 06:22 , Alec Mitchell wrote: > It would be very helpful to have these changes in Zope 2.12; > otherwise, Plone 4.0 will be stuck with our unmaintained > SecureMailHost product for yet another release in order to provide > equivalent functionality. Moving to a standard Zope MailHost would be > a big benefit for Plone, and all Zope users will benefit from the > ability to easily send properly formed non-ASCII messages. Andreas may be off on vacation already. IMHO this is a great example where code developed for Plone is pushed to the _correct_ place in the stack to benefit everyone. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqFCBQACgkQRAx5nvEhZLKJvgCePef8P/XuCgCXV/kXr0KcD3KM HEcAn36wv8S5d2mWCk2/YUciJlVEW4oa =sRi9 -----END PGP SIGNATURE----- From ems174 at psu.edu Fri Aug 14 16:57:24 2009 From: ems174 at psu.edu (Eric Steele) Date: Fri Aug 14 16:57:35 2009 Subject: [Framework-Team] Re: [Plone-developers] Adding dependency on plone.registry In-Reply-To: References: Message-ID: <45011225-D947-4711-A62D-ADB1205CBA9C@psu.edu> On Aug 14, 2009, at 8:14 AM, Geir B?kholt wrote: > > In our work on the collections-PLIPs: #9283 and #9295 > https://dev.plone.org/plone/ticket/9283 > https://dev.plone.org/plone/ticket/9295 > > ?we have found a need to persistently store configuration data. Our > options are: > 1) either to write a new persistent utility/tool that keeps this data, > then adding new genericsetup handlers for it and all the work that > comes > along with this > or > 2)Use the shiny new plone.(app.)registry that Hanno has built for this > exact purpose (for Plone 5) > While this is a rather large dependency (it depends on z3c.form), we > believe the advantages outweigh the drawbacks. As this will probably > be > the de-facto standard of storing configuration data in the near future > anyway, it seems silly to spend big lots of work creating something > that > will be redundant in the near future. > The fourdigits-team also wants to use the registry for the TinyMCE- > plip: > https://dev.plone.org/plone/ticket/9249 > > We'll add the dependency now ? and hope that the framework team will > signal us as soon as possible if this change should be reverted. > > > -- > Geir B?kholt > > in collaboration with > Hanno Schlichting > Ralph Jacobs > Rob Gietema > Roel Bruggink > I'm generally in favor, with the stipulation that somebody takes ownership of getting it ready for real world use and it goes through its own FWT review process (to make sure it's "right", rather than for inclusion). CC'ing the FWT*, in the hopes that we can get some solid discussion on this now instead of waiting until next Wednesday's phone call. Eric * Though I'm sure all are subscribed to Plone-dev, I just want to push it somewhere they're more likely to notice it. From steve at dcn.org Fri Aug 14 23:32:07 2009 From: steve at dcn.org (Steve McMahon) Date: Fri Aug 14 23:32:54 2009 Subject: [Framework-Team] 9250 and 9256 ready for review Message-ID: <26a908b50908141632m2a7902f9q777d1207f153ac25@mail.gmail.com> #9250 - JQuery Tools integration and #9256 ? expand variables for plone.app.contentrules are ready for review! -- Steve McMahon Reid-McMahon, LLC steve@reidmcmahon.com steve@dcn.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20090814/ffaf21ad/attachment.htm From apm13 at columbia.edu Sat Aug 15 17:03:45 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Sat Aug 15 18:30:17 2009 Subject: [Framework-Team] Re: MailHost Improvements References: <4A8399BF.8070909@zopyx.com> <365118370908132122m211290dej29de6aaf3ed3105f@mail.gmail.com> Message-ID: On Thu, 13 Aug 2009 21:22:07 -0700, Alec Mitchell wrote: > On Wed, Aug 12, 2009 at 9:42 PM, Andreas Jung wrote: >> On 13.08.09 01:03, Alec Mitchell wrote: >>> Hello, >>> >>> I've been working on making Plone use the standard Zope MailHost ?in >>> place of the custom Products.SecureMailHost we've been using since >>> Plone 2.1 (See: http://dev.plone.org/plone/ticket/8814). ?During this >>> process I've run into a couple bugs in the MailHost implementation and >>> I believe it is missing some essential functionality. >>> >>> The most significant issue is that if you call send() with a >>> messageText containing just the message body, and that body has a ':' >>> in it (e.g. a url) the body will be treated as a header and you'll >>> send a nonsense message. ?The current implementation of send() also >>> puts a fairly large burden on developers who want to generate simple, >>> correctly encoded messages. ?Finally, send() relies heavily on the >>> long deprecated 'rfc822' and 'mimetools' modules which have been >>> removed from Python 3.0. >>> >>> I've attached a patch that updates MailHost to use the 'email' module >>> for parsing and generating messages. ?In addition to fixing the issues >>> that I ran across, and maintaining compatibility, it provides a number >>> of new features: >>> >>> * send and sendTemplate accept an optional charset argument. ?Using >>> this will set the content-type charset, as well as trigger appropriate >>> encoding if needed. >>> >>> * send and sendTemplate accept an optional msg_type argument which >>> will set the content type header for the message. >>> >>> * The messageText, mfrom, mto, and subject arguments may now be >>> unicode or encoded non-ascii strings, provided a charset is given. >>> Any unicode input will be automatically encoded to the provided >>> charset (or the default charset). ?Headers will be further encoded in >>> compliance with rfc2822. ?The message body will be further encoded >>> using a transfer encoding determined by the email.Charset registry >>> (e.g. 7bit for us-ascii, quoted-printable for utf-8 and iso8859, >>> base64 for most other encodings). >>> >>> * The messageText argument now accepts email.Message.Message objects >>> directly. >>> >>> I'm attaching a patch that includes these changes as well as tests for >>> all new functionality. ?I hope to integrate these changes into Zope >>> 2.12 before final release, but would like to hear the opinions of Zope >>> developers before committing. ?Though these are fairly significant >>> changes, I believe they provide very useful functionality as well as >>> at least one critical fix, while maintaining 100% compatibility. >> >> This comes very, very late. We are pretty close to a release. Please put >> the changes on the trunk only. >> We will check after my vacation if we can move it into the 2.12 beta. > > I've put my latest changes on Zope trunk. All the existing tests pass > (with a couple essentially cosmetic modifications in the MailHost > tests), and there are 14 new tests which verify both existing and new > functionality, as well as the fixed bugs. The new behavior should be > identical to the existing behavior when the new charset and msg_type > parameters aren't used, with the following exceptions: > > 1) Passing a message body containing a ':' no longer produces a nonsense > email. > 2) Providing unicode strings for the text or headers no longer results > in a garbage message (it may produce a UnicodeEncodeError though). > 3) 8bit (encoded) strings provided as headers will be converted to > 7bit, using encoding determined in messageText headers or the default > encoding. > > It would be very helpful to have these changes in Zope 2.12; > otherwise, Plone 4.0 will be stuck with our unmaintained > SecureMailHost product for yet another release in order to provide > equivalent functionality. Moving to a standard Zope MailHost would be > a big benefit for Plone, and all Zope users will benefit from the > ability to easily send properly formed non-ASCII messages. There's one additional significant change to Zope behavior here that I forgot to mention. The current implementation sets the python default email transfer and header encoding for 'utf-8' messages to 'quoted-printable', it normally defaults to 'base64'. This is essentially a cosmetic change and makes reading and debugging email messages much more straightforward. It also makes encoded mail less likely to be caught by SPAM filters (some of which dislike base64 mail on principle). At present this change causes one test in CMFDefault to fail, which I'm happy to fix. But it's also not a problem to just remove the line that sets the new 'utf-8' encoding, though I think it dpes have some important advantages. Alec From jens at dataflake.org Sat Aug 15 18:41:54 2009 From: jens at dataflake.org (Jens Vagelpohl) Date: Sat Aug 15 18:42:04 2009 Subject: [Framework-Team] Re: MailHost Improvements In-Reply-To: References: <4A8399BF.8070909@zopyx.com> <365118370908132122m211290dej29de6aaf3ed3105f@mail.gmail.com> Message-ID: <81A0528E-29E1-4CE0-9634-1AB12E81C325@dataflake.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Aug 15, 2009, at 19:03 , Alec Mitchell wrote: > There's one additional significant change to Zope behavior here that > I forgot to mention. The current implementation sets the python > default email transfer and header encoding for 'utf-8' messages to > 'quoted-printable', it normally defaults to 'base64'. This is > essentially a cosmetic change and makes reading and debugging email > messages much more straightforward. It also makes encoded mail less > likely to be caught by SPAM filters (some of which dislike base64 > mail on principle). > > At present this change causes one test in CMFDefault to fail, which > I'm happy to fix. But it's also not a problem to just remove the > line that sets the new 'utf-8' encoding, though I think it dpes have > some important advantages. I'm not an expert, but if quoted-printable is "better practice" then it should be used and the CMF test should be changed accordingly. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkqHAXIACgkQRAx5nvEhZLKBTQCfcHjWwaRkbRsDo57+bdK2hbsZ CkgAmwcsUFuH0rXBVvimieyeA+XBJ4aG =NHxE -----END PGP SIGNATURE----- From maurits at vanrees.org Sat Aug 15 20:01:50 2009 From: maurits at vanrees.org (Maurits van Rees) Date: Sat Aug 15 20:13:56 2009 Subject: [Framework-Team] Re: MailHost Improvements In-Reply-To: References: <4A8399BF.8070909@zopyx.com> <365118370908132122m211290dej29de6aaf3ed3105f@mail.gmail.com> Message-ID: <20090815200149.GA22832@ip4da647da.direct-adsl.nl> On Sat, Aug 15, 2009 at 10:03:45AM -0700, Alec Mitchell wrote: > There's one additional significant change to Zope behavior here that I > forgot to mention. The current implementation sets the python default > email transfer and header encoding for 'utf-8' messages to > 'quoted-printable', it normally defaults to 'base64'. This is > essentially a cosmetic change and makes reading and debugging email > messages much more straightforward. It also makes encoded mail less > likely to be caught by SPAM filters (some of which dislike base64 mail on > principle). I was about to voice a warning, pointing to documentation in the email.charset and email.quoprimime modules. But some testing with Chinese text pasted from http://en.wikipedia.org/wiki/Chinese_language and utf-8 encoded shows that using quoted-printable should work fine: First base64: >>> import email.base64mime >>> chinese = '\xe6\xb1\x89\xe8\xaf\xad/\xe6\xbc\xa2\xe8\xaa\x9e' >>> email.base64mime.body_encode(chinese) '5rGJ6K+tL+a8ouiqng==\n' >>> email.base64mime.body_decode(_) '\xe6\xb1\x89\xe8\xaf\xad/\xe6\xbc\xa2\xe8\xaa\x9e' >>> _ == chinese True Then quoted-printable: >>> import email.quoprimime >>> email.quoprimime.body_encode(chinese) '=E6=B1=89=E8=AF=AD/=E6=BC=A2=E8=AA=9E' >>> email.quoprimime.body_decode(_) '\xe6\xb1\x89\xe8\xaf\xad/\xe6\xbc\xa2\xe8\xaa\x9e' >>> _ == chinese True > At present this change causes one test in CMFDefault to fail, which I'm > happy to fix. But it's also not a problem to just remove the line that > sets the new 'utf-8' encoding, though I think it does have some important > advantages. I'd say go ahead. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "Yes, we study economics, got to make the money make some kind of sense." - Geoff Mann From maurits at vanrees.org Sun Aug 16 00:14:07 2009 From: maurits at vanrees.org (Maurits van Rees) Date: Sun Aug 16 00:26:16 2009 Subject: [Framework-Team] Plip 9214 (email logins) ready for review Message-ID: <20090816001407.GC22832@ip4da647da.direct-adsl.nl> Hi all, Plip 9214, support logins using e-mail address instead of user id, is ready for review. Ticket: https://dev.plone.org/plone/ticket/9214 Accompanying notes: https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.0/plips/plip9214-emaillogins.txt Cheers, -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "Yes, we study economics, got to make the money make some kind of sense." - Geoff Mann From apm13 at columbia.edu Sun Aug 16 03:23:43 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Sun Aug 16 03:23:48 2009 Subject: [Framework-Team] PLIP 8814 ready for review Message-ID: <365118370908152023j23ca7f83lf59f9b59e6235dd8@mail.gmail.com> Hi all, The SecureMailHost removal PLIP is ready for review. Alec From wichert at wiggy.net Sun Aug 16 07:27:27 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Sun Aug 16 07:27:25 2009 Subject: [Framework-Team] Plip 9214 (email logins) ready for review In-Reply-To: <20090816001407.GC22832@ip4da647da.direct-adsl.nl> References: <20090816001407.GC22832@ip4da647da.direct-adsl.nl> Message-ID: <4A87B4DF.3070406@wiggy.net> On 2009-8-16 02:14, Maurits van Rees wrote: > Hi all, > > Plip 9214, support logins using e-mail address instead of user id, is > ready for review. > > Ticket: > https://dev.plone.org/plone/ticket/9214 > > Accompanying notes: > https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.0/plips/plip9214-emaillogins.txt Can you explain why using email addresses as login is a configuration option in site_properties instead of on a PAS plugin? All authentication configuration is on PAS plugins, so I would expect this to be there as well. If you use the email address as login than user.getUserName() must also return the email address, so the changes in PasswordResetTool should not be needed. Looking at the notes this PLIP is creating a situation where a user logs in with something that is not the users login name, which is a pretty big deviation from standard behaviour, and I am not sure if that is desirable. I think 'Offer migration of current login names to email addresses' item from the further-ideas list should be mandatory. Looking at your further ideas: email addresses are defined to be case sensitive in their local-part (not in the domain name), so lowercasing will technically violate standards. In reality I don't think any MTA is case sensitive (as witnessed by the fact that postmaster@domain works everywhere while the RFC defines Postmaster@domain) so this might still be a good thing to do from a user experience perspective. It does deserve a clear warning in the documentation. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From az at zitc.de Sun Aug 16 23:20:59 2009 From: az at zitc.de (Andreas Zeidler) Date: Sun Aug 16 23:21:29 2009 Subject: [Framework-Team] PLIPs 7822 (blob support) and 9316 (unified folders) ready for review... Message-ID: <13D595E0-D5E0-442A-9A3F-2AC0DF33698D@zitc.de> hi framework team, here's a heads-up regarding my PLIPs: #7822: Make standard file content types use ZODB BLOB support #9316: Unify folder implementations both PLIPs still need upgrades and fixes wrt plone 4.0, but are in a reviewable state nevertheless. or so i think. the main reason for this is that the packages behind these PLIPs ? `plone.app.blob`(+`plone.app.imaging`) and `plone.folder` +`plone.app.folder` ? were originally developed as add-ons for plone 3.x. all of them are in a near-finished state as such, and are (or will be as of wednesday) in production use. however, changes in the way the test setup works in zope 2.12 (the `custom_zodb.py` trick doesn't seem to be supported anymore) as well as a project deadline have so far prevented me from making the necessary fixes regarding plone 4.0. as the functionality provided will not change anymore, i think an initial review could already be conducted anyway. i've update the respective PLIP tickets to reflect the current state, and will add review notes as well as make the necessary fixes to let the tests pass again asap. iow, sorry about being late! i hope you will accept the state of the PLIP packages wrt plone 3.x as a good enough reason to consider reviewing them and allow me a few more days to catch up with the upgrades made for plone 4.0. regards, andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc5 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090817/e8f67fe4/PGP.pgp From az at zitc.de Mon Aug 17 00:38:04 2009 From: az at zitc.de (Andreas Zeidler) Date: Mon Aug 17 00:38:34 2009 Subject: [Framework-Team] Re: PLIPs 7822 (blob support) and 9316 (unified folders) ready for review... In-Reply-To: <13D595E0-D5E0-442A-9A3F-2AC0DF33698D@zitc.de> References: <13D595E0-D5E0-442A-9A3F-2AC0DF33698D@zitc.de> Message-ID: <2C60BE8D-3BEB-482E-93C0-506519658B16@zitc.de> On Aug 17, 2009, at 1:20 AM, Andreas Zeidler wrote: > here's a heads-up regarding my PLIPs: > > #7822: Make standard file content types use ZODB BLOB support > #9316: Unify folder implementations > > both PLIPs still need upgrades and fixes wrt plone 4.0, but are in a > reviewable state nevertheless. after r29056 all `plone.app.folder` and `plone.folder` tests do also pass on plone 4.0. the latter are only found when using `bin/instance test -s plone.folder` (i.e. not with `bin/test -s plone.folder`) for some reason, but i guess this doesn't matter too much atm. my guess is that this might be the case, because they're all unit tests. in any case, PLIP 9316 is "ready for review" now, pending the required review notes. i'll put those together tomorrow. also, some manual tests indicate that blob support is also working as expected in plone 4.0, which means that the failing tests are very likely only caused by the differences in test setup. as i said, i'll try to fix this asap, but the package itself can be reviewed (and tested ttw). review notes are also still missing here, sorry. good night, andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc5 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090817/42880709/PGP.pgp From az at zitc.de Mon Aug 17 01:36:36 2009 From: az at zitc.de (Andreas Zeidler) Date: Mon Aug 17 01:37:03 2009 Subject: [Framework-Team] Re: PLIPs 7822 (blob support) and 9316 (unified folders) ready for review... In-Reply-To: <2C60BE8D-3BEB-482E-93C0-506519658B16@zitc.de> References: <13D595E0-D5E0-442A-9A3F-2AC0DF33698D@zitc.de> <2C60BE8D-3BEB-482E-93C0-506519658B16@zitc.de> Message-ID: <2E6715A0-0043-44AB-BE40-97CD34EB0E2C@zitc.de> On Aug 17, 2009, at 2:38 AM, Andreas Zeidler wrote: > [...] in any case, PLIP 9316 is "ready for review" now, pending the > required review notes. review notes are in now. > good night, > > > andi -- zeidler it consulting - http://zitc.de/ - info@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.3rc5 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090817/6182a542/PGP.pgp From limi at plone.org Mon Aug 17 04:52:45 2009 From: limi at plone.org (Alexander Limi) Date: Mon Aug 17 04:53:36 2009 Subject: [Framework-Team] =?windows-1252?q?Status_of_PLIP_9315_=97_New_th?= =?windows-1252?q?eme_for_Plone_4?= Message-ID: I ran into unexpected problems today while trying to wrap up my PLIP for the review today ? in short, there doesn't seem to be any (!) way to get any version of Plone running on OS X 10.6 (Snow Leopard) at the moment: The Unified Installers fail, buildout-based install fails, and any combination of MacPorts Python (current release, trunk from their SVN), binary Python and GCC (4.0, 4.2) versions fail while compiling parts of Zope. I spent 6 hours today with the help of messieurs Glick, Steele and McMahon today trying to make it work, but there's something very weird going on (for example, the Acquisition egg compiles properly, but after reporting that it's successfully compiled, can't be found ? if you're interested, here's the output ). (And if you know what's going on here, it would be great if you can help out, since we also need to solve this ? preferrably before Snow Leopard is released, which may be as soon as end of this month.) Since I have fully migrated to Snow Leopard on my work laptop as part of testing Firefox on 10.6 (and that happened just before my vacation), I need to locate a computer that runs OS 10.5 before I can put together the running version of the theme product. Here's what I put together before I went on vacation, and that I have on my laptop at the moment: - An updated main_template that uses HTML5 (XHTML variant) that adds various structural elements like and various other cleanups. No changes to class/ID structure so far, though ? so existing themes should work. (the only exception is if they do stuff like table.* in CSS, ie. depend on the tag instead of the class/ID name). HTML5 renders fine in all browsers, btw ? they just don't style the new elements, which we aren't putting visual styles on anyway. - A tested, robust grid system (the same as I have shown at Plone Symposium East, and that we'll use for Plone 5) that supports both fixed and fluid widths. No tables in the layout anymore. Works in IE6 too. - A new design from Iain (screenshot) that I have implemented as a static HTML version on top of the Plone markup (with the main_template changes. Note that the typography and pull-down menu will be different ? closer to what you see on plone.org right now. - A new CSS that implement's Iain's layout with the changes discussed in the ticket. Still missing are things like print CSS and (if I get the time) a mobile/iPhone stylesheet using the @media selector. - CSS doesn't use base_properties, but is color-neutral except for a couple of properties (e.g. link color) that are pulled out separately to the top of the CSS file, so they are easy to override, should you need to. No DTML magic. - Three-column layout approach is intact for Plone 4, we'll move to a freer layout as part of Plone 5, so no change here either. - A theme skeleton ? plonetheme.sunburst? that Denys checked in for me while I was flying across the Atlantic. Unfortunately this is just a blank skeleton still, since I can't get Plone running at the moment. What's missing was to pull these together on top of the current Plone 4 checkout, which should take 4-6 hours including basic testing to have something ready for the first review deadline. I completed the core of the work before I went on vacation, and knew that I would only have one day when returning from vacation to put together the package, so I had the entire day reserved to complete the actual theme product. Unfortunately, there seems to be no way I can get Plone running on my current laptop, so I have to find another computer to do it on. I'm going to humbly (and embarrassingly) ask for your permission to submit my PLIP for review late ? I have access to a computer running OS X 10.5 tomorrow, so I will most likely have it ready by the end of Monday/Tuesday. I assume you have enough to do the first 24 hours of the PLIP submission deadline that it won't feel like you're lacking things to do in the meantime. :) It sucks, and I'm sorry ? I really didn't expect this to be an issue at all. -- Alexander Limi ? http://limi.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20090816/e4b4473b/attachment.htm From senger at rehfisch.de Mon Aug 17 05:13:55 2009 From: senger at rehfisch.de (Carsten Senger) Date: Mon Aug 17 05:14:00 2009 Subject: [Framework-Team] PLIP 9321 (searchform) ready for review Message-ID: <7A2E32458BB408DC059A2B58@kolja> Hi all, the Implementation for PLIP 9321: Reimplement the search form with an eye on usability is ready for review. Plip ticket: (Note: The final Proposal is ) The Notes to the implementation are here: ..Carsten From wichert at wiggy.net Mon Aug 17 07:08:11 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Mon Aug 17 07:08:18 2009 Subject: =?windows-1252?Q?Re=3A_=5BFramework-Team=5D_Status_of_PL?= =?windows-1252?Q?IP_9315_=97_New_theme_for_Plone_4?= In-Reply-To: References: Message-ID: <4A8901DB.6020606@wiggy.net> On 8/17/09 06:52 , Alexander Limi wrote: > * CSS doesn't use base_properties, but is color-neutral except for a > couple of properties (e.g. link color) that are pulled out > separately to the top of the CSS file, so they are easy to > override, should you need to. No DTML magic. Please note that at least three framework team members only approved the theme PLIP on the condition that base_properties keeps working, something Joel Burton also explicitly asked for. Wichert. From matthew at matthewwilkes.co.uk Mon Aug 17 08:17:35 2009 From: matthew at matthewwilkes.co.uk (Matthew Wilkes) Date: Mon Aug 17 08:23:51 2009 Subject: =?WINDOWS-1252?Q?Re:_[Framework-Team]_Status_of_PLIP_9315_=97_Ne?= =?WINDOWS-1252?Q?w_theme_for_Plone_4?= In-Reply-To: References: Message-ID: > ? A new design from Iain (screenshot) that I have implemented as a > static HTML version on top of the Plone markup (with the > main_template changes. Note that the typography and pull-down menu > will be different ? closer to what you see on plone.org right now. Is that the new design for Plone? Last I heard from Matt at netsight (just before he went on holiday) was that it was now only being used as an inspiration. That theme is in the collective as plonetheme.netsightintranet > ? CSS doesn't use base_properties, but is color-neutral except for > a couple of properties (e.g. link color) that are pulled out > separately to the top of the CSS file, so they are easy to override, > should you need to. No DTML magic. I'm -1 on inclusion, then. DTML magic is good magic and I made it clear it was a condition from my POV. > ? A theme skeleton ? plonetheme.sunburst ? that Denys checked in > for me while I was flying across the Atlantic. Unfortunately this is > just a blank skeleton still, since I can't get Plone running at the > moment. How does this relate to zopeskel? Matt From hanno at hannosch.eu Mon Aug 17 09:44:49 2009 From: hanno at hannosch.eu (Hanno Schlichting) Date: Mon Aug 17 10:08:15 2009 Subject: =?UTF-8?Q?Re=3A_=5BFramework=2DTeam=5D_Status_of_PLIP_9315_=E2=80=94_New_the?= =?UTF-8?Q?me_for_Plone_4?= In-Reply-To: References: Message-ID: <5cae42b20908170244sf2bb26alcf18eff39b59545e@mail.gmail.com> On Mon, Aug 17, 2009 at 6:52 AM, Alexander Limi wrote: > I ran into unexpected problems today while trying to wrap up my PLIP for the > review today ? in short, there doesn't seem to be any (!) way to get any > version of Plone running on OS X 10.6 (Snow Leopard) at the moment: The > Unified Installers fail, buildout-based install fails, and any combination > of MacPorts Python (current release, trunk from their SVN), binary Python > and GCC (4.0, 4.2) versions fail while compiling parts of Zope. I'm surprised you got even as far as this ;) I'd expected there to be more problems with Snow Leopard. > I spent 6 hours today with the help of messieurs Glick, Steele and McMahon > today trying to make it work, but there's something very weird going on (for > example, the Acquisition egg compiles properly, but after reporting that > it's successfully compiled, can't be found ? if you're interested, here's > the output). (And if you know what's going on here, it would be great if you > can help out, since we also need to solve this ? preferrably before Snow > Leopard is released, which may be as soon as end of this month.) What looks suspicious is this line: Installed /Users/limi/.buildout/eggs/tmpiT6PqP/Acquisition-2.12.3-py2.6-macosx-10.6-universal.egg it seems setuptools gets the build platform correct (10.6-universal) but fails to move the egg into the correct location. Or at least I assume your egg cache is not "~/.buildout/eggs/tmpiT6PqP" but "~/.buildout/eggs/". I'd fear we need people with the right knowledge to get access to Snow Leopard to debug and fix this, which might take a bit more time. At least with Distribute we now have a means of actually getting those fixes out to the world. Hanno From mj at zopatista.com Mon Aug 17 10:13:18 2009 From: mj at zopatista.com (Martijn Pieters) Date: Mon Aug 17 10:13:46 2009 Subject: =?UTF-8?Q?Re=3A_=5BFramework=2DTeam=5D_Status_of_PLIP_9315_=E2=80=94_New_the?= =?UTF-8?Q?me_for_Plone_4?= In-Reply-To: <5cae42b20908170244sf2bb26alcf18eff39b59545e@mail.gmail.com> References: <5cae42b20908170244sf2bb26alcf18eff39b59545e@mail.gmail.com> Message-ID: <21a6ef160908170313v3e81f1d1tdfd15ccc67c11baf@mail.gmail.com> On Mon, Aug 17, 2009 at 11:44, Hanno Schlichting wrote: > What looks suspicious is this line: > > Installed /Users/limi/.buildout/eggs/tmpiT6PqP/Acquisition-2.12.3-py2.6-macosx-10.6-universal.egg > > it seems setuptools gets the build platform correct (10.6-universal) > but fails to move the egg into the correct location. Or at least I > assume your egg cache is not "~/.buildout/eggs/tmpiT6PqP" but > "~/.buildout/eggs/". That's because the egg is zipped, and gets unzipped in a temp dir to access the extension. -- Martijn Pieters From ems174 at psu.edu Mon Aug 17 12:30:15 2009 From: ems174 at psu.edu (Eric Steele) Date: Mon Aug 17 12:30:25 2009 Subject: =?WINDOWS-1252?Q?Re:_[Framework-Team]_Status_of_PLIP_9315_=97_Ne?= =?WINDOWS-1252?Q?w_theme_for_Plone_4?= In-Reply-To: References: Message-ID: <4608581A-2F02-43E4-A24A-7ACA2E6FBA12@psu.edu> On Aug 17, 2009, at 4:17 AM, Matthew Wilkes wrote: ... >> ? A theme skeleton ? plonetheme.sunburst ? that Denys checked in >> for me while I was flying across the Atlantic. Unfortunately this >> is just a blank skeleton still, since I can't get Plone running at >> the moment. > > How does this relate to zopeskel? > plonetheme.sunburst is a zopeskel-created theme. It just doesn't have anything in it yet. I believe that's what he means by "skeleton". Eric From ems174 at psu.edu Mon Aug 17 13:31:15 2009 From: ems174 at psu.edu (Eric Steele) Date: Mon Aug 17 13:31:23 2009 Subject: [Framework-Team] PLIPs ready for review Message-ID: The following 27 PLIPs have been indicated as being ready for review: 7822 Make standard file content types use ZODB BLOB support 8801 Move action icon support into actions, remove CMFActionIcons 8802 Move our upgrade / migration infrastructure to GenericSetup 8808 Require Python 2.5 or 2.6, Zope 2.12, and CMF 2.2 for Plone 4.0 8814 Replace SecureMailHost with a standard Zope mailhost 9186 Set Image IDs from Title field 9214 Support logins using e-mail address instead of user id 9249 Add TinyMCE as the default visual editor 9250 Add jQuery Tools to base install 9256 Expand variable substitution in mailing action of plone.app.contentrules 9258 Replace Products.ATReferenceBrowserWidget with archetypes.referencebrowserwidget 9259 Group dashboards 9263 GenericSetup syntax for importing Sharing page roles 9264 Merge backport patches from plone.app.dexterity into Plone 9272 Exposing and editing Dublin Core properties 9284 Allow views to override skin layer elements easily 9285 Show blocked portlets in management interface 9288 Improved commenting infrastructure 9295 Improved UI for collections (merged with 9283 for review: A more lightweight backend for collections) 9305 Use real names instead of usernames 9309 Better search for East Asian (multi-byte) languages. 9316 Unify folder implementations 9321 Reimplement the search form with an eye on usability 9327 Unified interface for lists of content 9330 Add ability to choose role when adding new site members 9352 Search results improvements We also have 2 PLIPs that depend on the outcome of the theme PLIP and will require a later review: 8805 Do not ship with NuPlone anymore 9300 Well formed, valid XHTML And two that are installer options: 9314 Plone "Developer Pack" option for installers 9322 Ensure that Plone 4 can upgrade Zope on Windows and Mac OS X via binary eggs (See our spreadsheet for the full list of PLIPs http://spreadsheets.google.com/ccc?key=rR4UAIObeTZtdUExfYophHw) If we stick with the 2 reviewers/PLIP that we'd discussed last week, that means at least 6 reviews per FWT member. I'm going to make the assumption that you'll want some help with these. I think there are some cases where we'd be best served having one FWT review and one external review for a PLIP. Hanno has offered to pitch in and I'd like to see him review David's backporting PLIPs. Some would benefit greatly from a UI team reviewer (do we need a UI review of the collections work since half of the UI team worked on it?) I've also asked accessibility evangelist Christian Vinten-Johansen here at WebLion to look at some of these for possible accessibility issues. If there are others you'd like to bring in, let me know and I'll make it happen. Our deadline for reviews is August 30. We can discuss the feasibility of that during Wednesday's call. Eric From rsa at eurotux.com Mon Aug 17 15:23:27 2009 From: rsa at eurotux.com (Ricardo Alves) Date: Mon Aug 17 15:23:47 2009 Subject: [Framework-Team] PLIPs ready for review In-Reply-To: References: Message-ID: <4A8975EF.4040107@eurotux.com> Hi, I've just submitted for review plip #9286, and I'll be wrapping up PLIP #9329 until the end of the day. I hope it won't be too late to include it into the review process. Sorry for the delay :) Thanks, Ricardo Eric Steele wrote: > The following 27 PLIPs have been indicated as being ready for review: > > 7822 Make standard file content types use ZODB BLOB support > 8801 Move action icon support into actions, remove CMFActionIcons > 8802 Move our upgrade / migration infrastructure to GenericSetup > 8808 Require Python 2.5 or 2.6, Zope 2.12, and CMF 2.2 for Plone 4.0 > 8814 Replace SecureMailHost with a standard Zope mailhost > 9186 Set Image IDs from Title field > 9214 Support logins using e-mail address instead of user id > 9249 Add TinyMCE as the default visual editor > 9250 Add jQuery Tools to base install > 9256 Expand variable substitution in mailing action of > plone.app.contentrules > 9258 Replace Products.ATReferenceBrowserWidget with > archetypes.referencebrowserwidget > 9259 Group dashboards > 9263 GenericSetup syntax for importing Sharing page roles > 9264 Merge backport patches from plone.app.dexterity into Plone > 9272 Exposing and editing Dublin Core properties > 9284 Allow views to override skin layer elements easily > 9285 Show blocked portlets in management interface > 9288 Improved commenting infrastructure > 9295 Improved UI for collections (merged with 9283 for review: A > more lightweight backend for collections) > 9305 Use real names instead of usernames > 9309 Better search for East Asian (multi-byte) languages. > 9316 Unify folder implementations > 9321 Reimplement the search form with an eye on usability > 9327 Unified interface for lists of content > 9330 Add ability to choose role when adding new site members > 9352 Search results improvements > > We also have 2 PLIPs that depend on the outcome of the theme PLIP and > will require a later review: > 8805 Do not ship with NuPlone anymore > 9300 Well formed, valid XHTML > > And two that are installer options: > 9314 Plone "Developer Pack" option for installers > 9322 Ensure that Plone 4 can upgrade Zope on Windows and Mac OS X > via binary eggs > > (See our spreadsheet for the full list of PLIPs > http://spreadsheets.google.com/ccc?key=rR4UAIObeTZtdUExfYophHw) > > If we stick with the 2 reviewers/PLIP that we'd discussed last week, > that means at least 6 reviews per FWT member. I'm going to make the > assumption that you'll want some help with these. I think there are > some cases where we'd be best served having one FWT review and one > external review for a PLIP. Hanno has offered to pitch in and I'd like > to see him review David's backporting PLIPs. Some would benefit > greatly from a UI team reviewer (do we need a UI review of the > collections work since half of the UI team worked on it?) > > I've also asked accessibility evangelist Christian Vinten-Johansen > here at WebLion to look at some of these for possible accessibility > issues. > > If there are others you'd like to bring in, let me know and I'll make > it happen. > > Our deadline for reviews is August 30. We can discuss the feasibility > of that during Wednesday's call. > > Eric > > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team -- Ricardo Alves Eurotux From ems174 at psu.edu Mon Aug 17 23:59:16 2009 From: ems174 at psu.edu (Eric Steele) Date: Mon Aug 17 23:59:26 2009 Subject: [Framework-Team] Re: PLIPs ready for review In-Reply-To: References: Message-ID: Since we've only had 4 spots claimed today, I'll put all of this another way... last one to get their 6 PLIPs picked has to review David's Zope migration. :P Eric On Aug 17, 2009, at 9:31 AM, Eric Steele wrote: > The following 27 PLIPs have been indicated as being ready for review: > > 7822 Make standard file content types use ZODB BLOB support > 8801 Move action icon support into actions, remove CMFActionIcons > 8802 Move our upgrade / migration infrastructure to GenericSetup > 8808 Require Python 2.5 or 2.6, Zope 2.12, and CMF 2.2 for Plone 4.0 > 8814 Replace SecureMailHost with a standard Zope mailhost > 9186 Set Image IDs from Title field > 9214 Support logins using e-mail address instead of user id > 9249 Add TinyMCE as the default visual editor > 9250 Add jQuery Tools to base install > 9256 Expand variable substitution in mailing action of > plone.app.contentrules > 9258 Replace Products.ATReferenceBrowserWidget with > archetypes.referencebrowserwidget > 9259 Group dashboards > 9263 GenericSetup syntax for importing Sharing page roles > 9264 Merge backport patches from plone.app.dexterity into Plone > 9272 Exposing and editing Dublin Core properties > 9284 Allow views to override skin layer elements easily > 9285 Show blocked portlets in management interface > 9288 Improved commenting infrastructure > 9295 Improved UI for collections (merged with 9283 for review: A > more lightweight backend for collections) > 9305 Use real names instead of usernames > 9309 Better search for East Asian (multi-byte) languages. > 9316 Unify folder implementations > 9321 Reimplement the search form with an eye on usability > 9327 Unified interface for lists of content > 9330 Add ability to choose role when adding new site members > 9352 Search results improvements > > We also have 2 PLIPs that depend on the outcome of the theme PLIP > and will require a later review: > 8805 Do not ship with NuPlone anymore > 9300 Well formed, valid XHTML > > And two that are installer options: > 9314 Plone "Developer Pack" option for installers > 9322 Ensure that Plone 4 can upgrade Zope on Windows and Mac OS X > via binary eggs > > (See our spreadsheet for the full list of PLIPs http://spreadsheets.google.com/ccc?key=rR4UAIObeTZtdUExfYophHw) > > If we stick with the 2 reviewers/PLIP that we'd discussed last week, > that means at least 6 reviews per FWT member. I'm going to make the > assumption that you'll want some help with these. I think there are > some cases where we'd be best served having one FWT review and one > external review for a PLIP. Hanno has offered to pitch in and I'd > like to see him review David's backporting PLIPs. Some would benefit > greatly from a UI team reviewer (do we need a UI review of the > collections work since half of the UI team worked on it?) > > I've also asked accessibility evangelist Christian Vinten-Johansen > here at WebLion to look at some of these for possible accessibility > issues. > > If there are others you'd like to bring in, let me know and I'll > make it happen. > > Our deadline for reviews is August 30. We can discuss the > feasibility of that during Wednesday's call. > > Eric From davidglick at onenw.org Tue Aug 18 06:26:07 2009 From: davidglick at onenw.org (David Glick) Date: Tue Aug 18 06:26:57 2009 Subject: [Framework-Team] Re: PLIPs ready for review In-Reply-To: References: Message-ID: On Aug 17, 2009, at 4:59 PM, Eric Steele wrote: > Since we've only had 4 spots claimed today, I'll put all of this > another way... last one to get their 6 PLIPs picked has to review > David's Zope migration. :P Except me; I can procrastinate with impunity. :-p Just kidding; I picked out a few and got started looking at things during my flight today. You all should try it, it's fun :) David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidglick@onenw.org 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 From m.van.rees at zestsoftware.nl Tue Aug 18 10:45:42 2009 From: m.van.rees at zestsoftware.nl (Maurits van Rees) Date: Tue Aug 18 12:09:19 2009 Subject: [Framework-Team] Plip 9214 (email logins) ready for review In-Reply-To: <4A87B4DF.3070406@wiggy.net> References: <20090816001407.GC22832@ip4da647da.direct-adsl.nl> <4A87B4DF.3070406@wiggy.net> Message-ID: <20090818104542.GE5907@kronos.zestsoftware.nl> Hi Wichert, Thanks for the feedback. On Sun, Aug 16, 2009 at 09:27:27AM +0200, Wichert Akkerman wrote: > On 2009-8-16 02:14, Maurits van Rees wrote: >> Hi all, >> >> Plip 9214, support logins using e-mail address instead of user id, is >> ready for review. >> >> Ticket: >> https://dev.plone.org/plone/ticket/9214 >> >> Accompanying notes: >> https://dev.plone.org/plone/browser/buildouts/plone-coredev/branches/4.0/plips/plip9214-emaillogins.txt > > Can you explain why using email addresses as login is a configuration > option in site_properties instead of on a PAS plugin? All authentication > configuration is on PAS plugins, so I would expect this to be there as > well. Mostly because what I did here was already working in the collective.emaillogin package that I created for a client together with Guido Wesdorp. This has worked for one and a half years now at that client, so I would say it is proven technology. Well, in that package the only 'configuration option' was: if you want email logins, install this package. :) But the real work was done not in a PAS plugin but by some patches. I think in whatever way you do it in the background (a plugin or some changes like I did now) you need a config option in the plone control panel. Based on this setting you can show something different in, for example, the registration and login forms. Turning this option on could instead set the priority of the plugins in the background (and get its value by checking this priority). Arguably you could make a small browser view or function to check if an emaillogin pas plugin is at the top and use that in the spots where I am now using the property setting. For me the property fits with the rest of the security control panel. I am aware of the recent betahaus.emaillogin package that does this as a PAS plugin. I have not tried it out, but last time I looked at the code it looked like it should work. I like my method more. Also, I am highly biased. :) > If you use the email address as login than user.getUserName() must also > return the email address, so the changes in PasswordResetTool should not > be needed. That only works as long as you have not changed your email address yet, as then the userid (member.getId()), login name and email address are still all the same. skins/PasswordReset/registered_notify_template.pt passes member.getId() to the requestReset method of PasswordResetTool. If you have changed your email address and then reset your password, then resetting will fail without these changes. When I remove those changes I indeed get a failing test in bin/test -s Products.CMFPlone -m testEmailLogin > Looking at the notes this PLIP is creating a situation where > a user logs in with something that is not the users login name, which is > a pretty big deviation from standard behaviour, and I am not sure if > that is desirable. Actually, logging in still only works with your login name. Without the use_email_as_login setting the login name is the same as the user id; with that setting the login name is the same as the email address. What can be strange, and that may be what you mean, is that changing this setting does not in fact change the current login name of existing users. That only happens after they save their personalize form. That is also mentioned on the security panel BTW. > I think 'Offer migration of current login names to > email addresses' item from the further-ideas list should be mandatory. I'll await comments from the framework team, but yes, I want to add this. Have not had time yet. > Looking at your further ideas: email addresses are defined to be case > sensitive in their local-part (not in the domain name), so lowercasing > will technically violate standards. In reality I don't think any MTA is > case sensitive (as witnessed by the fact that postmaster@domain works > everywhere while the RFC defines Postmaster@domain) so this might still > be a good thing to do from a user experience perspective. It does > deserve a clear warning in the documentation. I wonder if we would be opening up security issue by allowing one user to have user@example.org as login and another to have USER@example.org. But I cannot come up with a backdoor here. Being able to use these two address could be handy for admins if they have to test something (though admins probably have enough email addresses already), so we probably do not need to do any lowercasing here. Cheers, -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "Yes, we study economics, got to make the money make some kind of sense." - Geoff Mann From ems174 at psu.edu Wed Aug 19 01:28:02 2009 From: ems174 at psu.edu (Eric Steele) Date: Wed Aug 19 01:28:15 2009 Subject: [Framework-Team] Reminder: August 19th Conference call Message-ID: FWT, Just a reminder that we have a conference call Wednesday, August 19 at 19:00 UTC. We'll be divvying up the remaining PLIP review duties, considering who else to bring in to help shoulder the load, and reevaluating our timeline. Don't forget to choose your PLIP review assignments at http://bit.ly/plips . If you'll be unable to attend, please let me know ahead of time. Thanks, Eric From limi at plone.org Wed Aug 19 07:02:07 2009 From: limi at plone.org (Alexander Limi) Date: Wed Aug 19 07:02:56 2009 Subject: [Framework-Team] =?windows-1252?q?Re=3A_Status_of_PLIP_9315_=97_?= =?windows-1252?q?New_theme_for_Plone_4?= In-Reply-To: References: Message-ID: The first cut of the theme is checked in, with related buildout.cfg and review notes. To address some of the questions brought up in the thread: *Why are you not supporting base_properties?* It doesn't make a lot of sense, since there are only two properties that are adjustable, and that is easier to do by pulling them out and putting them first in the CSS. The upside of having standard CSS files that can be fed to CSS editors and other tools outweighs the dynamicism that variables for these would give us. And for a person new to Plone theming, DTML and the ZMI is a lot more intimidating than two hex values in a well-known and predictable format. * Is this another version of **plonetheme.netsightintranet? *Nope, it was just used for inspiration, sorry about not being specific enough with my explanation. As you can see, the Sunburst theme looks slightly different. Hopefully everything else is addressed by the review notes, but if you have additional questions, let me know. I'll be refining the theme further over the next few days, start testing in IE, etc. -- Alexander Limi ? http://limi.net On Sun, Aug 16, 2009 at 9:52 PM, Alexander Limi wrote: > I ran into unexpected problems today while trying to wrap up my PLIP for > the review today ? in short, there doesn't seem to be any (!) way to get any > version of Plone running on OS X 10.6 (Snow Leopard) at the moment: The > Unified Installers fail, buildout-based install fails, and any combination > of MacPorts Python (current release, trunk from their SVN), binary Python > and GCC (4.0, 4.2) versions fail while compiling parts of Zope. > > I spent 6 hours today with the help of messieurs Glick, Steele and McMahon > today trying to make it work, but there's something very weird going on (for > example, the Acquisition egg compiles properly, but after reporting that > it's successfully compiled, can't be found ? if you're interested, here's > the output ). (And if you know what's going > on here, it would be great if you can help out, since we also need to solve > this ? preferrably before Snow Leopard is released, which may be as soon as > end of this month.) > > Since I have fully migrated to Snow Leopard on my work laptop as part of > testing Firefox on 10.6 (and that happened just before my vacation), I need > to locate a computer that runs OS 10.5 before I can put together the running > version of the theme product. > > Here's what I put together before I went on vacation, and that I have on my > laptop at the moment: > > - An updated main_template that uses HTML5 (XHTML variant) that adds > various structural elements like and various other cleanups. No > changes to class/ID structure so far, though ? so existing themes should > work. (the only exception is if they do stuff like table.* in CSS, ie. > depend on the tag instead of the class/ID name). HTML5 renders fine in all > browsers, btw ? they just don't style the new elements, which we aren't > putting visual styles on anyway. > - A tested, robust grid system (the same as I have shown at Plone > Symposium East, and that we'll use for Plone 5) that supports both fixed and > fluid widths. No tables in the layout anymore. Works in IE6 too. > - A new design from Iain (screenshot) > that I have implemented as a static HTML version on top of the Plone markup > (with the main_template changes. Note that the typography and pull-down menu > will be different ? closer to what you see on plone.org right now. > - A new CSS that implement's Iain's layout with the changes discussed > in the ticket. Still missing are things like print CSS and (if I get the > time) a mobile/iPhone stylesheet using the @media selector. > - CSS doesn't use base_properties, but is color-neutral except for a > couple of properties (e.g. link color) that are pulled out separately to the > top of the CSS file, so they are easy to override, should you need to. No > DTML magic. > - Three-column layout approach is intact for Plone 4, we'll move to a > freer layout as part of Plone 5, so no change here either. > - A theme skeleton ? plonetheme.sunburst? that Denys checked in for me while I was flying across the Atlantic. > Unfortunately this is just a blank skeleton still, since I can't get Plone > running at the moment. > > What's missing was to pull these together on top of the current Plone 4 > checkout, which should take 4-6 hours including basic testing to have > something ready for the first review deadline. I completed the core of the > work before I went on vacation, and knew that I would only have one day when > returning from vacation to put together the package, so I had the entire day > reserved to complete the actual theme product. Unfortunately, there seems to > be no way I can get Plone running on my current laptop, so I have to find > another computer to do it on. > > I'm going to humbly (and embarrassingly) ask for your permission to submit > my PLIP for review late ? I have access to a computer running OS X 10.5 > tomorrow, so I will most likely have it ready by the end of Monday/Tuesday. > I assume you have enough to do the first 24 hours of the PLIP submission > deadline that it won't feel like you're lacking things to do in the > meantime. :) > > It sucks, and I'm sorry ? I really didn't expect this to be an issue at > all. > > -- > Alexander Limi ? http://limi.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20090819/531d9b05/attachment.htm From az at zitc.de Thu Aug 20 04:54:42 2009 From: az at zitc.de (Andreas Zeidler) Date: Thu Aug 20 04:55:34 2009 Subject: [Board] Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor In-Reply-To: <4A847509.6000306@wiggy.net> References: <53479e250907270438m6d2c7e9fl842624df8a362296@mail.gmail.com> <4A6DEDAE.5020709@wiggy.net> <878wia3rb2.fsf@transitory.lefae.org> <365118370907271301v6f7d6ea3hbfb16d78e5875e8d@mail.gmail.com> <5E9659FF-E077-4BD7-A1B6-E641A32AF643@jarn.com> <4A6E9A2E.4020804@wiggy.net> <5ACD15BF-FBE7-40BC-A9F4-5623D1B0B3CA@jarn.com> <5af21ed10907282301g115dc362i5d90540a7306d52@mail.gmail.com> <4A847509.6000306@wiggy.net> Message-ID: On Aug 13, 2009, at 10:18 PM, Wichert Akkerman wrote: > On 2009-8-13 22:16, Alexander Limi wrote: >> FWIW, Mozilla runs their entire project without a contributor >> agreement >> ? so we are already way ahead of what most large open source >> projects do >> on this front. :) > > Or way behind when shit hits your fan. Those agreements exists for > good reasons. i think alex' "we" referred to plone here, not mozilla... ;) andi -- zeidler it consulting - http://zitc.de/ - info@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.3 released! -- http://plone.org/products/plone/ -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.plone.org/pipermail/framework-team/attachments/20090820/537425dc/PGP.pgp From wichert at wiggy.net Thu Aug 20 06:38:44 2009 From: wichert at wiggy.net (Wichert Akkerman) Date: Thu Aug 20 06:38:41 2009 Subject: [Board] Re: [Framework-Team] Re: [Plone 4] PLIP #9249 Add TinyMCE as the default visual editor In-Reply-To: References: <53479e250907270438m6d2c7e9fl842624df8a362296@mail.gmail.com> <4A6DEDAE.5020709@wiggy.net> <878wia3rb2.fsf@transitory.lefae.org> <365118370907271301v6f7d6ea3hbfb16d78e5875e8d@mail.gmail.com> <5E9659FF-E077-4BD7-A1B6-E641A32AF643@jarn.com> <4A6E9A2E.4020804@wiggy.net> <5ACD15BF-FBE7-40BC-A9F4-5623D1B0B3CA@jarn.com> <5af21ed10907282301g115dc362i5d90540a7306d52@mail.gmail.com> <4A847509.6000306@wiggy.net> Message-ID: <4A8CEF74.5030006@wiggy.net> On 2009-8-20 06:54, Andreas Zeidler wrote: > On Aug 13, 2009, at 10:18 PM, Wichert Akkerman wrote: >> On 2009-8-13 22:16, Alexander Limi wrote: >>> FWIW, Mozilla runs their entire project without a contributor agreement >>> ? so we are already way ahead of what most large open source projects do >>> on this front. :) >> >> Or way behind when shit hits your fan. Those agreements exists for >> good reasons. > > i think alex' "we" referred to plone here, not mozilla... ;) yay for language ambiguity :) Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From francesco.ciriaci at gmail.com Fri Aug 21 12:45:48 2009 From: francesco.ciriaci at gmail.com (Francesco Ciriaci) Date: Fri Aug 21 12:46:20 2009 Subject: =?WINDOWS-1252?Q?Re:_[Framework-Team]_Re:_Status_of_PLIP_9315_?= =?WINDOWS-1252?Q?=97_New_theme_for_Plone_4?= In-Reply-To: References: Message-ID: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> Hi Alex, you know I've always been interested in the default theme of Plone. I'm really curious about the new "refresh" of Plone. If you need some help for the visual design I'd glad to give some of my time. There is also a couple of people in Reflab/Mediatria that are willing to contribute: Antonio, who works mostly on UI and JS and Giulio who's a visual designer and skinner. Also consider that the work we did back in old days of Plone 3 (October 2007) with Capri and other themes were precisely aimed into "refreshing" the Plone default theme with: 1) updated logo (had been officially announced a couple of days before the sprint) 2) updated (and extended) icon theme 3) accessibility (contrasts/colors included) 4) have a base theme for skinning 5) "recongnizable" / keeping Plone visual identity 6) nice use of typography 7) new use of colors for user actions and portlets 8) grid (fixed width) I'm glad to see that many of these elements plus some new one "fluid", HTML5, etc. are in the PLIP: nice work! I'm not sure how the review/PLIP process works for the visual design but I'd also bring the new design to the attention of the Plone evangelism team, just for a feedback. Then, once the PLIP is approved, it would be interesting to *promote* the new visual design and especially it's implementation. Let us know what we can do. Cheers, Francesco. Il giorno 19/ago/09, alle ore 09:02, Alexander Limi ha scritto: > The first cut of the theme is checked in, with related buildout.cfg > and review notes. > > To address some of the questions brought up in the thread: > > Why are you not supporting base_properties? It doesn't make a lot of > sense, since there are only two properties that are adjustable, and > that is easier to do by pulling them out and putting them first in > the CSS. The upside of having standard CSS files that can be fed to > CSS editors and other tools outweighs the dynamicism that variables > for these would give us. And for a person new to Plone theming, DTML > and the ZMI is a lot more intimidating than two hex values in a well- > known and predictable format. > > Is this another version of plonetheme.netsightintranet? Nope, it was > just used for inspiration, sorry about not being specific enough > with my explanation. As you can see, the Sunburst theme looks > slightly different. > > Hopefully everything else is addressed by the review notes, but if > you have additional questions, let me know. I'll be refining the > theme further over the next few days, start testing in IE, etc. > > -- > Alexander Limi ? http://limi.net > > > On Sun, Aug 16, 2009 at 9:52 PM, Alexander Limi > wrote: > I ran into unexpected problems today while trying to wrap up my PLIP > for the review today ? in short, there doesn't seem to be any (!) > way to get any version of Plone running on OS X 10.6 (Snow Leopard) > at the moment: The Unified Installers fail, buildout-based install > fails, and any combination of MacPorts Python (current release, > trunk from their SVN), binary Python and GCC (4.0, 4.2) versions > fail while compiling parts of Zope. > > I spent 6 hours today with the help of messieurs Glick, Steele and > McMahon today trying to make it work, but there's something very > weird going on (for example, the Acquisition egg compiles properly, > but after reporting that it's successfully compiled, can't be found > ? if you're interested, here's the output). (And if you know what's > going on here, it would be great if you can help out, since we also > need to solve this ? preferrably before Snow Leopard is released, > which may be as soon as end of this month.) > > Since I have fully migrated to Snow Leopard on my work laptop as > part of testing Firefox on 10.6 (and that happened just before my > vacation), I need to locate a computer that runs OS 10.5 before I > can put together the running version of the theme product. > > Here's what I put together before I went on vacation, and that I > have on my laptop at the moment: > An updated main_template that uses HTML5 (XHTML variant) that adds > various structural elements like and various other > cleanups. No changes to class/ID structure so far, though ? so > existing themes should work. (the only exception is if they do stuff > like table.* in CSS, ie. depend on the tag instead of the class/ID > name). HTML5 renders fine in all browsers, btw ? they just don't > style the new elements, which we aren't putting visual styles on > anyway. > A tested, robust grid system (the same as I have shown at Plone > Symposium East, and that we'll use for Plone 5) that supports both > fixed and fluid widths. No tables in the layout anymore. Works in > IE6 too. > A new design from Iain (screenshot) that I have implemented as a > static HTML version on top of the Plone markup (with the > main_template changes. Note that the typography and pull-down menu > will be different ? closer to what you see on plone.org right now. > A new CSS that implement's Iain's layout with the changes discussed > in the ticket. Still missing are things like print CSS and (if I get > the time) a mobile/iPhone stylesheet using the @media selector. > CSS doesn't use base_properties, but is color-neutral except for a > couple of properties (e.g. link color) that are pulled out > separately to the top of the CSS file, so they are easy to override, > should you need to. No DTML magic. > Three-column layout approach is intact for Plone 4, we'll move to a > freer layout as part of Plone 5, so no change here either. > A theme skeleton ? plonetheme.sunburst ? that Denys checked in for > me while I was flying across the Atlantic. Unfortunately this is > just a blank skeleton still, since I can't get Plone running at the > moment. > What's missing was to pull these together on top of the current > Plone 4 checkout, which should take 4-6 hours including basic > testing to have something ready for the first review deadline. I > completed the core of the work before I went on vacation, and knew > that I would only have one day when returning from vacation to put > together the package, so I had the entire day reserved to complete > the actual theme product. Unfortunately, there seems to be no way I > can get Plone running on my current laptop, so I have to find > another computer to do it on. > > I'm going to humbly (and embarrassingly) ask for your permission to > submit my PLIP for review late ? I have access to a computer running > OS X 10.5 tomorrow, so I will most likely have it ready by the end > of Monday/Tuesday. I assume you have enough to do the first 24 hours > of the PLIP submission deadline that it won't feel like you're > lacking things to do in the meantime. :) > > It sucks, and I'm sorry ? I really didn't expect this to be an issue > at all. > > -- > Alexander Limi ? http://limi.net > > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team -- Ideas and the ability to implement them. http://twitter.com/fciriaci http://www.linkedin.com/in/francescociriaci http://facebook.com/francescociriaci -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20090821/2caf62df/attachment.htm From apm13 at columbia.edu Fri Aug 21 16:01:39 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Fri Aug 21 16:01:45 2009 Subject: =?windows-1252?Q?Re=3A_=5BFramework=2DTeam=5D_Re=3A_Status_of_PLIP_9315_=97_New?= =?windows-1252?Q?_theme_for_Plone_4?= In-Reply-To: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> References: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> Message-ID: <365118370908210901k55cccedi425df9bf84af8292@mail.gmail.com> Hi Francesco, If you'd like to volunteer to do a UI review of this PLIP or any of the other UI intensive PLIPs, it could be a big help to our review process. If so, let us know which PLIPs you'd be interested in reviewing. Of course if Alex needs your help with implementation, then your time would probably be better spent there :-) Best wishes, Alec On Fri, Aug 21, 2009 at 5:45 AM, Francesco Ciriaci wrote: > Hi Alex, > you know I've always been interested in the default theme of Plone. I'm > really curious about the new "refresh" of Plone. > If you need some help for the visual design I'd glad to give some of my > time. There is also a?couple of people in Reflab/Mediatria that are willing > to contribute: Antonio, who works mostly on UI and JS and Giulio who's a > visual designer and skinner. > Also consider that the work we did back in old days of Plone 3 (October > 2007) with Capri and other themes were precisely aimed into "refreshing" the > Plone default theme with: > 1) updated logo (had been officially announced a couple of days before the > sprint) > 2) updated (and extended) icon theme > 3) accessibility (contrasts/colors included) > 4) have a base theme for skinning > 5) "recongnizable" / keeping Plone visual identity > 6) nice use of typography > 7) new use of colors for user actions and portlets > 8) grid (fixed width) > I'm glad to see that many of these elements plus some new one "fluid", > HTML5, etc. are in the PLIP: nice work! > I'm not sure how the review/PLIP process works for the visual design but I'd > also bring the new design to the attention of the Plone evangelism team, > just for a feedback. Then, once the PLIP is approved, it would be > interesting to *promote* the new visual design and especially it's > implementation. > Let us know what we can do. From francesco.ciriaci at gmail.com Fri Aug 21 16:30:45 2009 From: francesco.ciriaci at gmail.com (Francesco Ciriaci) Date: Fri Aug 21 16:30:53 2009 Subject: =?WINDOWS-1252?Q?Re:_[Framework-Team]_Re:_Status_of_PLIP_9315_?= =?WINDOWS-1252?Q?=97_New_theme_for_Plone_4?= In-Reply-To: <365118370908210901k55cccedi425df9bf84af8292@mail.gmail.com> References: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> <365118370908210901k55cccedi425df9bf84af8292@mail.gmail.com> Message-ID: <09ED6C8F-1AC2-4208-A8D6-37BC84B1FD2F@gmail.com> The main 9315 PLIP for sure. I'm also interested in the 9321 (search), 9288 (commenting) and 9295 (collections). I'm sorry I do not understand why the time spent with implementation could be more useful/valuable that the one spent on review/design... anyway. For the implementation I can help mostly putting Antonio and Giulio on it: I'm very bad in writing code. Really. Cheers, Francesco. Il giorno 21/ago/09, alle ore 18:01, Alec Mitchell ha scritto: > Hi Francesco, > > If you'd like to volunteer to do a UI review of this PLIP or any of > the other UI intensive PLIPs, it could be a big help to our review > process. If so, let us know which PLIPs you'd be interested in > reviewing. Of course if Alex needs your help with implementation, > then your time would probably be better spent there :-) > > Best wishes, > Alec > > On Fri, Aug 21, 2009 at 5:45 AM, Francesco > Ciriaci wrote: >> Hi Alex, >> you know I've always been interested in the default theme of Plone. >> I'm >> really curious about the new "refresh" of Plone. >> If you need some help for the visual design I'd glad to give some >> of my >> time. There is also a couple of people in Reflab/Mediatria that are >> willing >> to contribute: Antonio, who works mostly on UI and JS and Giulio >> who's a >> visual designer and skinner. >> Also consider that the work we did back in old days of Plone 3 >> (October >> 2007) with Capri and other themes were precisely aimed into >> "refreshing" the >> Plone default theme with: >> 1) updated logo (had been officially announced a couple of days >> before the >> sprint) >> 2) updated (and extended) icon theme >> 3) accessibility (contrasts/colors included) >> 4) have a base theme for skinning >> 5) "recongnizable" / keeping Plone visual identity >> 6) nice use of typography >> 7) new use of colors for user actions and portlets >> 8) grid (fixed width) >> I'm glad to see that many of these elements plus some new one >> "fluid", >> HTML5, etc. are in the PLIP: nice work! >> I'm not sure how the review/PLIP process works for the visual >> design but I'd >> also bring the new design to the attention of the Plone evangelism >> team, >> just for a feedback. Then, once the PLIP is approved, it would be >> interesting to *promote* the new visual design and especially it's >> implementation. >> Let us know what we can do. -- Ideas and the ability to implement them. http://twitter.com/fciriaci http://www.linkedin.com/in/francescociriaci http://facebook.com/francescociriaci From senger at rehfisch.de Fri Aug 21 17:19:37 2009 From: senger at rehfisch.de (Carsten Senger) Date: Fri Aug 21 17:19:41 2009 Subject: =?UTF-8?Q?Re:_[Framework-Team]_Re:_Status_of_PLIP_9315_=E2=80=94_New?= =?UTF-8?Q?_theme_for_Plone_4?= In-Reply-To: <09ED6C8F-1AC2-4208-A8D6-37BC84B1FD2F@gmail.com> References: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> <365118370908210901k55cccedi425df9bf84af8292@mail.gmail.com> <09ED6C8F-1AC2-4208-A8D6-37BC84B1FD2F@gmail.com> Message-ID: <43DAAAA1DB56ACBE3A1A6F6C@kolja> Hi Francesco, --On Freitag, August 21, 2009 18:30:45 +0200 Francesco Ciriaci wrote: > The main 9315 PLIP for sure. I'm also interested in the 9321 (search), > 9288 (commenting) and 9295 (collections). I did not have time to polish the ui for #9321 before the deadline and probably won't work on it while Erik and Calvin do their reviews. But I'm glad for everybody who does a ui review to get feedback. ..Carsten > Il giorno 21/ago/09, alle ore 18:01, Alec Mitchell ha scritto: > >> Hi Francesco, >> >> If you'd like to volunteer to do a UI review of this PLIP or any of >> the other UI intensive PLIPs, it could be a big help to our review >> process. If so, let us know which PLIPs you'd be interested in >> reviewing. Of course if Alex needs your help with implementation, >> then your time would probably be better spent there :-) >> >> Best wishes, >> Alec >> >> On Fri, Aug 21, 2009 at 5:45 AM, Francesco >> Ciriaci wrote: >>> Hi Alex, >>> you know I've always been interested in the default theme of Plone. >>> I'm >>> really curious about the new "refresh" of Plone. >>> If you need some help for the visual design I'd glad to give some >>> of my >>> time. There is also a couple of people in Reflab/Mediatria that are >>> willing >>> to contribute: Antonio, who works mostly on UI and JS and Giulio >>> who's a >>> visual designer and skinner. >>> Also consider that the work we did back in old days of Plone 3 >>> (October >>> 2007) with Capri and other themes were precisely aimed into >>> "refreshing" the >>> Plone default theme with: >>> 1) updated logo (had been officially announced a couple of days >>> before the >>> sprint) >>> 2) updated (and extended) icon theme >>> 3) accessibility (contrasts/colors included) >>> 4) have a base theme for skinning >>> 5) "recongnizable" / keeping Plone visual identity >>> 6) nice use of typography >>> 7) new use of colors for user actions and portlets >>> 8) grid (fixed width) >>> I'm glad to see that many of these elements plus some new one >>> "fluid", >>> HTML5, etc. are in the PLIP: nice work! >>> I'm not sure how the review/PLIP process works for the visual >>> design but I'd >>> also bring the new design to the attention of the Plone evangelism >>> team, >>> just for a feedback. Then, once the PLIP is approved, it would be >>> interesting to *promote* the new visual design and especially it's >>> implementation. >>> Let us know what we can do. > > -- > Ideas and the ability to implement them. > > http://twitter.com/fciriaci > http://www.linkedin.com/in/francescociriaci > http://facebook.com/francescociriaci > > > > > > > > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team From limi at plone.org Mon Aug 24 06:56:59 2009 From: limi at plone.org (Alexander Limi) Date: Mon Aug 24 06:57:47 2009 Subject: =?windows-1252?Q?Re=3A_=5BFramework=2DTeam=5D_Re=3A_Status_of_PLIP_9315_=97_New?= =?windows-1252?Q?_theme_for_Plone_4?= In-Reply-To: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> References: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> Message-ID: You're a bit late, seeing as the initial deadline was last week. ;) But feel free to check out the current version and give feedback on what's there ? it's unlikely to change significantly in the general approach and design, but more eyes are always better. Let me know if you find issues in addition to the ones listed in the review notes. I spent quite a lot of time fixing bugs and adding print/mobile CSS etc this weekend, and will continue improving it in the coming weeks. Thanks for getting involved and helping with testing it! -- Alexander Limi ? http://limi.net On Fri, Aug 21, 2009 at 5:45 AM, Francesco Ciriaci < francesco.ciriaci@gmail.com> wrote: > Hi Alex, > > you know I've always been interested in the default theme of Plone. I'm > really curious about the new "refresh" of Plone. > If you need some help for the visual design I'd glad to give some of my > time. There is also a couple of people in Reflab/Mediatria that are willing > to contribute: Antonio, who works mostly on UI and JS and Giulio who's a > visual designer and skinner. > > Also consider that the work we did back in old days of Plone 3 (October > 2007) with Capri and other themes were precisely aimed into "refreshing" the > Plone default theme with: > 1) updated logo (had been officially announced a couple of days before the > sprint) > 2) updated (and extended) icon theme > 3) accessibility (contrasts/colors included) > 4) have a base theme for skinning > 5) "recongnizable" / keeping Plone visual identity > 6) nice use of typography > 7) new use of colors for user actions and portlets > 8) grid (fixed width) > > I'm glad to see that many of these elements plus some new one "fluid", > HTML5, etc. are in the PLIP: nice work! > > I'm not sure how the review/PLIP process works for the visual design but > I'd also bring the new design to the attention of the Plone evangelism team, > just for a feedback. Then, once the PLIP is approved, it would be > interesting to *promote* the new visual design and especially it's > implementation. > > Let us know what we can do. > Cheers, Francesco. > > > Il giorno 19/ago/09, alle ore 09:02, Alexander Limi ha scritto: > > The first cut of the theme is checked in, with related buildout.cfg and > review notes. > > To address some of the questions brought up in the thread: > > *Why are you not supporting base_properties?* It doesn't make a lot of > sense, since there are only two properties that are adjustable, and that is > easier to do by pulling them out and putting them first in the CSS. The > upside of having standard CSS files that can be fed to CSS editors and other > tools outweighs the dynamicism that variables for these would give us. And > for a person new to Plone theming, DTML and the ZMI is a lot more > intimidating than two hex values in a well-known and predictable format. > * > Is this another version of **plonetheme.netsightintranet? *Nope, it was > just used for inspiration, sorry about not being specific enough with my > explanation. As you can see, the Sunburst theme looks slightly different. > > Hopefully everything else is addressed by the review notes, but if you have > additional questions, let me know. I'll be refining the theme further over > the next few days, start testing in IE, etc. > > -- > Alexander Limi ? http://limi.net > > > On Sun, Aug 16, 2009 at 9:52 PM, Alexander Limi wrote: > >> I ran into unexpected problems today while trying to wrap up my PLIP for >> the review today ? in short, there doesn't seem to be any (!) way to get any >> version of Plone running on OS X 10.6 (Snow Leopard) at the moment: The >> Unified Installers fail, buildout-based install fails, and any combination >> of MacPorts Python (current release, trunk from their SVN), binary Python >> and GCC (4.0, 4.2) versions fail while compiling parts of Zope. >> >> I spent 6 hours today with the help of messieurs Glick, Steele and McMahon >> today trying to make it work, but there's something very weird going on (for >> example, the Acquisition egg compiles properly, but after reporting that >> it's successfully compiled, can't be found ? if you're interested, here's >> the output ). (And if you know what's going >> on here, it would be great if you can help out, since we also need to solve >> this ? preferrably before Snow Leopard is released, which may be as soon as >> end of this month.) >> >> Since I have fully migrated to Snow Leopard on my work laptop as part of >> testing Firefox on 10.6 (and that happened just before my vacation), I need >> to locate a computer that runs OS 10.5 before I can put together the running >> version of the theme product. >> >> Here's what I put together before I went on vacation, and that I have on >> my laptop at the moment: >> >> - An updated main_template that uses HTML5 (XHTML variant) that adds >> various structural elements like and various other cleanups. No >> changes to class/ID structure so far, though ? so existing themes should >> work. (the only exception is if they do stuff like table.* in CSS, ie. >> depend on the tag instead of the class/ID name). HTML5 renders fine in all >> browsers, btw ? they just don't style the new elements, which we aren't >> putting visual styles on anyway. >> - A tested, robust grid system (the same as I have shown at Plone >> Symposium East, and that we'll use for Plone 5) that supports both fixed and >> fluid widths. No tables in the layout anymore. Works in IE6 too. >> - A new design from Iain (screenshot) >> that I have implemented as a static HTML version on top of the Plone markup >> (with the main_template changes. Note that the typography and pull-down menu >> will be different ? closer to what you see on plone.org right now. >> - A new CSS that implement's Iain's layout with the changes discussed >> in the ticket. Still missing are things like print CSS and (if I get the >> time) a mobile/iPhone stylesheet using the @media selector. >> - CSS doesn't use base_properties, but is color-neutral except for a >> couple of properties (e.g. link color) that are pulled out separately to the >> top of the CSS file, so they are easy to override, should you need to. No >> DTML magic. >> - Three-column layout approach is intact for Plone 4, we'll move to a >> freer layout as part of Plone 5, so no change here either. >> - A theme skeleton ? plonetheme.sunburst? that Denys checked in for me while I was flying across the Atlantic. >> Unfortunately this is just a blank skeleton still, since I can't get Plone >> running at the moment. >> >> What's missing was to pull these together on top of the current Plone 4 >> checkout, which should take 4-6 hours including basic testing to have >> something ready for the first review deadline. I completed the core of the >> work before I went on vacation, and knew that I would only have one day when >> returning from vacation to put together the package, so I had the entire day >> reserved to complete the actual theme product. Unfortunately, there seems to >> be no way I can get Plone running on my current laptop, so I have to find >> another computer to do it on. >> >> I'm going to humbly (and embarrassingly) ask for your permission to submit >> my PLIP for review late ? I have access to a computer running OS X 10.5 >> tomorrow, so I will most likely have it ready by the end of Monday/Tuesday. >> I assume you have enough to do the first 24 hours of the PLIP submission >> deadline that it won't feel like you're lacking things to do in the >> meantime. :) >> >> It sucks, and I'm sorry ? I really didn't expect this to be an issue at >> all. >> >> -- >> Alexander Limi ? http://limi.net >> > > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > > > -- > Ideas and the ability to implement them. > > http://twitter.com/fciriaci > http://www.linkedin.com/in/francescociriaci > http://facebook.com/francescociriaci > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20090823/0af79996/attachment.htm From l at lrowe.co.uk Mon Aug 24 14:14:20 2009 From: l at lrowe.co.uk (Laurence Rowe) Date: Mon Aug 24 14:14:52 2009 Subject: [Framework-Team] Re: [Plone-developers] Adding dependency on plone.registry In-Reply-To: <45011225-D947-4711-A62D-ADB1205CBA9C@psu.edu> References: <45011225-D947-4711-A62D-ADB1205CBA9C@psu.edu> Message-ID: I'm +1 on including plone.registry. I'm also +1 on including a z3c.form as a dependency - with Zope 2.12 we won't need the whole pinning pain required for use with. Zope 2.10. Laurence 2009/8/14 Eric Steele : > > On Aug 14, 2009, at 8:14 AM, Geir B?kholt wrote: > >> >> In our work on the collections-PLIPs: #9283 and #9295 >> https://dev.plone.org/plone/ticket/9283 >> https://dev.plone.org/plone/ticket/9295 >> >> ?we have found a need to persistently store configuration data. Our >> options are: >> 1) either to write a new persistent utility/tool that keeps this data, >> then adding new genericsetup handlers for it and all the work that comes >> along with this >> or >> 2)Use the shiny new plone.(app.)registry that Hanno has built for this >> exact purpose (for Plone 5) >> While this is a rather large dependency (it depends on z3c.form), we >> believe the advantages outweigh the drawbacks. As this will probably be >> the de-facto standard of storing configuration data in the near future >> anyway, it seems silly to spend big lots of work creating something that >> ?will be redundant in the near future. >> The fourdigits-team also wants to use the registry for the TinyMCE-plip: >> https://dev.plone.org/plone/ticket/9249 >> >> We'll add the dependency now ? and hope that the framework team will >> signal us as soon as possible if this change should be reverted. >> >> >> -- >> Geir B?kholt >> >> in collaboration with >> Hanno Schlichting >> Ralph Jacobs >> Rob Gietema >> Roel Bruggink >> > > I'm generally in favor, with the stipulation that somebody takes ownership > of getting it ready for real world use and it goes through its own FWT > review process (to make sure it's "right", rather than for inclusion). > > CC'ing the FWT*, in the hopes that we can get some solid discussion on this > now instead of waiting until next Wednesday's phone call. > > Eric > > * Though I'm sure all are subscribed to Plone-dev, I just want to push it > somewhere they're more likely to notice it. > _______________________________________________ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > From francesco.ciriaci at gmail.com Mon Aug 24 14:17:06 2009 From: francesco.ciriaci at gmail.com (Francesco Ciriaci) Date: Mon Aug 24 14:17:39 2009 Subject: =?WINDOWS-1252?Q?Re:_[Framework-Team]_Re:_Status_of_PLIP_9315_?= =?WINDOWS-1252?Q?=97_New_theme_for_Plone_4?= In-Reply-To: References: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> Message-ID: <249B5E7E-FA30-44FD-A15C-9B592BD0B513@gmail.com> Il giorno 24/ago/09, alle ore 08:56, Alexander Limi ha scritto: > You're a bit late, seeing as the initial deadline was last week. ;) Well, I'm trying to follow the framework and developers lists but the only screenshot with a new visual design I found was on your mail dated 21 August. I must have a problems with email, too: about 4 months ago I proposed to help with the new visual design of Plone 4, but did not get any real answer, proposition, or contact. Frankly I'm struggling in trying to help improving Plone, lately. Anyway: I'll check out the code and review what I see there. I don't want to bother the framework team so I'll then report directly to you and use the tracker. cheers, Francesco. > > But feel free to check out the current version and give feedback on > what's there ? it's unlikely to change significantly in the general > approach and design, but more eyes are always better. Let me know if > you find issues in addition to the ones listed in the review notes. > > I spent quite a lot of time fixing bugs and adding print/mobile CSS > etc this weekend, and will continue improving it in the coming weeks. > > Thanks for getting involved and helping with testing it! > > -- > Alexander Limi ? http://limi.net > > > On Fri, Aug 21, 2009 at 5:45 AM, Francesco Ciriaci > wrote: > Hi Alex, > > you know I've always been interested in the default theme of Plone. > I'm really curious about the new "refresh" of Plone. > If you need some help for the visual design I'd glad to give some of > my time. There is also a couple of people in Reflab/Mediatria that > are willing to contribute: Antonio, who works mostly on UI and JS > and Giulio who's a visual designer and skinner. > > Also consider that the work we did back in old days of Plone 3 > (October 2007) with Capri and other themes were precisely aimed into > "refreshing" the Plone default theme with: > 1) updated logo (had been officially announced a couple of days > before the sprint) > 2) updated (and extended) icon theme > 3) accessibility (contrasts/colors included) > 4) have a base theme for skinning > 5) "recongnizable" / keeping Plone visual identity > 6) nice use of typography > 7) new use of colors for user actions and portlets > 8) grid (fixed width) > > I'm glad to see that many of these elements plus some new one > "fluid", HTML5, etc. are in the PLIP: nice work! > > I'm not sure how the review/PLIP process works for the visual design > but I'd also bring the new design to the attention of the Plone > evangelism team, just for a feedback. Then, once the PLIP is > approved, it would be interesting to *promote* the new visual design > and especially it's implementation. > > Let us know what we can do. > Cheers, Francesco. > > > Il giorno 19/ago/09, alle ore 09:02, Alexander Limi ha scritto: > >> The first cut of the theme is checked in, with related buildout.cfg >> and review notes. >> >> To address some of the questions brought up in the thread: >> >> Why are you not supporting base_properties? It doesn't make a lot >> of sense, since there are only two properties that are adjustable, >> and that is easier to do by pulling them out and putting them first >> in the CSS. The upside of having standard CSS files that can be fed >> to CSS editors and other tools outweighs the dynamicism that >> variables for these would give us. And for a person new to Plone >> theming, DTML and the ZMI is a lot more intimidating than two hex >> values in a well-known and predictable format. >> >> Is this another version of plonetheme.netsightintranet? Nope, it >> was just used for inspiration, sorry about not being specific >> enough with my explanation. As you can see, the Sunburst theme >> looks slightly different. >> >> Hopefully everything else is addressed by the review notes, but if >> you have additional questions, let me know. I'll be refining the >> theme further over the next few days, start testing in IE, etc. >> >> -- >> Alexander Limi ? http://limi.net >> >> >> On Sun, Aug 16, 2009 at 9:52 PM, Alexander Limi >> wrote: >> I ran into unexpected problems today while trying to wrap up my >> PLIP for the review today ? in short, there doesn't seem to be any >> (!) way to get any version of Plone running on OS X 10.6 (Snow >> Leopard) at the moment: The Unified Installers fail, buildout-based >> install fails, and any combination of MacPorts Python (current >> release, trunk from their SVN), binary Python and GCC (4.0, 4.2) >> versions fail while compiling parts of Zope. >> >> I spent 6 hours today with the help of messieurs Glick, Steele and >> McMahon today trying to make it work, but there's something very >> weird going on (for example, the Acquisition egg compiles properly, >> but after reporting that it's successfully compiled, can't be found >> ? if you're interested, here's the output). (And if you know what's >> going on here, it would be great if you can help out, since we also >> need to solve this ? preferrably before Snow Leopard is released, >> which may be as soon as end of this month.) >> >> Since I have fully migrated to Snow Leopard on my work laptop as >> part of testing Firefox on 10.6 (and that happened just before my >> vacation), I need to locate a computer that runs OS 10.5 before I >> can put together the running version of the theme product. >> >> Here's what I put together before I went on vacation, and that I >> have on my laptop at the moment: >> An updated main_template that uses HTML5 (XHTML variant) that adds >> various structural elements like and various other >> cleanups. No changes to class/ID structure so far, though ? so >> existing themes should work. (the only exception is if they do >> stuff like table.* in CSS, ie. depend on the tag instead of the >> class/ID name). HTML5 renders fine in all browsers, btw ? they just >> don't style the new elements, which we aren't putting visual styles >> on anyway. >> A tested, robust grid system (the same as I have shown at Plone >> Symposium East, and that we'll use for Plone 5) that supports both >> fixed and fluid widths. No tables in the layout anymore. Works in >> IE6 too. >> A new design from Iain (screenshot) that I have implemented as a >> static HTML version on top of the Plone markup (with the >> main_template changes. Note that the typography and pull-down menu >> will be different ? closer to what you see on plone.org right now. >> A new CSS that implement's Iain's layout with the changes discussed >> in the ticket. Still missing are things like print CSS and (if I >> get the time) a mobile/iPhone stylesheet using the @media selector. >> CSS doesn't use base_properties, but is color-neutral except for a >> couple of properties (e.g. link color) that are pulled out >> separately to the top of the CSS file, so they are easy to >> override, should you need to. No DTML magic. >> Three-column layout approach is intact for Plone 4, we'll move to a >> freer layout as part of Plone 5, so no change here either. >> A theme skeleton ? plonetheme.sunburst ? that Denys checked in for >> me while I was flying across the Atlantic. Unfortunately this is >> just a blank skeleton still, since I can't get Plone running at the >> moment. >> What's missing was to pull these together on top of the current >> Plone 4 checkout, which should take 4-6 hours including basic >> testing to have something ready for the first review deadline. I >> completed the core of the work before I went on vacation, and knew >> that I would only have one day when returning from vacation to put >> together the package, so I had the entire day reserved to complete >> the actual theme product. Unfortunately, there seems to be no way I >> can get Plone running on my current laptop, so I have to find >> another computer to do it on. >> >> I'm going to humbly (and embarrassingly) ask for your permission to >> submit my PLIP for review late ? I have access to a computer >> running OS X 10.5 tomorrow, so I will most likely have it ready by >> the end of Monday/Tuesday. I assume you have enough to do the first >> 24 hours of the PLIP submission deadline that it won't feel like >> you're lacking things to do in the meantime. :) >> >> It sucks, and I'm sorry ? I really didn't expect this to be an >> issue at all. >> >> -- >> Alexander Limi ? http://limi.net >> >> _______________________________________________ >> Framework-Team mailing list >> Framework-Team@lists.plone.org >> http://lists.plone.org/mailman/listinfo/framework-team > > -- > Ideas and the ability to implement them. > > http://twitter.com/fciriaci > http://www.linkedin.com/in/francescociriaci > http://facebook.com/francescociriaci > > > > > > > -- Ideas and the ability to implement them. http://twitter.com/fciriaci http://www.linkedin.com/in/francescociriaci http://facebook.com/francescociriaci -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.plone.org/pipermail/framework-team/attachments/20090824/7f47eddf/attachment-0001.htm From apm13 at columbia.edu Mon Aug 24 15:13:49 2009 From: apm13 at columbia.edu (Alec Mitchell) Date: Mon Aug 24 15:14:03 2009 Subject: =?windows-1252?Q?Re=3A_=5BFramework=2DTeam=5D_Re=3A_Status_of_PLIP_9315_=97_New?= =?windows-1252?Q?_theme_for_Plone_4?= In-Reply-To: <249B5E7E-FA30-44FD-A15C-9B592BD0B513@gmail.com> References: <773E129F-3EB7-482C-8A86-27DCA4274D2F@gmail.com> <249B5E7E-FA30-44FD-A15C-9B592BD0B513@gmail.com> Message-ID: <365118370908240813v1cbd8117v3c1f1c0c309ba980@mail.gmail.com> On Mon, Aug 24, 2009 at 7:17 AM, Francesco Ciriaci wrote: > > Il giorno 24/ago/09, alle ore 08:56, Alexander Limi ha scritto: > > You're a bit late, seeing as the initial deadline was last week. ;) > > Well, I'm trying to follow the framework and developers lists but the only > screenshot with a new visual design I found was on your mail dated 21 > August. > I must have a problems with email, too: about 4 months ago I proposed to > help with the new visual design of Plone 4, but did not get any real answer, > proposition, or contact.?Frankly I'm struggling in trying to help improving > Plone, lately. > Anyway: I'll check out the code and review what I see there. I don't want to > bother the framework team so I'll then report directly to you and use the > tracker. I promise you won't bother us. The more help we have, the better. Reviewing 36 PLIPs this week will probably send a few of us to an early grave :-) Alec From limi at plone.org Wed Aug 26 07:07:18 2009 From: limi at plone.org (Alexander Limi) Date: Wed Aug 26 07:13:55 2009 Subject: [Framework-Team] =?windows-1252?q?PLIP_9315_=97_New_Theme=2C_rev?= =?windows-1252?q?iew_feedback?= Message-ID: Thanks for the detailed review, Rob! It's great to get this kind of in-depth feedback early on. If you don't mind, I'd like to expand on some of the reasoning behind the choices so far, and correct some errors. :) Rob wrote: > - Skin folders are named: plonetheme_sunburst_custom_images, > plonetheme_sunburst_custom_templates and plonetheme_sunburst_styles. Adding > "custom" to first two doesn't seem to be logical. Better use > plonetheme_sunburst_images and plonetheme_sunburst_templates. Agreed, this is just what ZopeSkel produces by default ? and I don't touch stuff I don't know how works. If anyone wants to change it and make sure whatever registrations that reference it are updated, feel free to do it. Last time I tried, my theme product was not functional anymore. > - setuphandlers.py is empty but is called from the import_steps. If this file > isn't used better remove it. > > - templates and viewlets.py in the browser folder seem to be unused and should > be removed. > > - jsregistry.xml and viewlets.xml are empty, better remove them. The idea is to have a final review at the end where we remove all the files that aren't useful for the core theme. It's quite shocking to see just how much crap is required in Plone 3 to add some simple templates. But yes, as few files as possible is definitely the goal. > - All css validated except main.css. The errors are caused by the use of rounded > corners and rgba colors. Since this will become the default theme I suggest > sticking to the current CSS standards and move these extra features to a > separate css file so the integrator can choose to use it or not. This is valid CSS3, and is also what we're already using CSS3 properties in Plone 3. I'm not sure whether the validator is showing regressions, or what's going on ? I'm pretty sure I didn't get errors on rgba properties earlier, but I might be wrong. There was one legitimate error (cursor property), which I have fixed. The rest seem like validator software bugs. :( > - member.css uses a lot of unneeded !important statements. These statement make > css debugging a lot harder. I know people have a reflexive dislike of !important, and I took great care not to use any in the main style sheets. However, for the state coloring, they are necessary, since you don't actually know what kind of elements they are used on, and what other CSS is applied. The state color should always take precedence when it's specified, so we have to use !important. I agree with the principle of not using !important, but this is one of the few cases where it is actually warranted. > - Html validation failed with 20 errors and 32 warnings. If you switch the validator to HTML5 and add the doctype as noted, there are no errors in templates I tested. An important concern when deciding on whether to adopt HTML5 or not was whether pointing the validator at it would cause issues ? but luckily it already supports HTML5. > - No doctype specified (as noted in the plip). > > - No character encoding specified (should be the first meta). These are valid concerns. > - Search form uses "name" attribute.> This is allowed in HTML5. > - Label of searchbox not inside block element. This is allowed in HTML5. > - History form uses input which is not inside block element.> This is allowed in HTML5. > - All html5 tags are not recognized. See above. ;) > - The following issues do not meet the accessibility requirements: > > - Not all images and symbols have a text equivalent (alt tag) I couldn't find any from my casual testing. Which templates were these? Note that we supply empty alt tags if the image has no usefulness to the meaning of the page. FWIW, it passes the accessibility tester at http://wave.webaim.org. > - When javascript is disabled the "Display", "Add new" and "State" menu's are > visible. Good catch, thanks! This is a legitimate issue, but seems to be unrelated to the theme. The theme CSS has dl.actionMenu.deactivated dd { display: none; } ? but it seems that the menu rendering code doesn't apply this class anymore (or does it using JS). I can't really tell where the "deactivated" class supposed to come from. I suspect the same bug exists in current Plone 3 releases. > - Some values are specified using 'px' where they should be specified as a > relative value like em or %. Right, there were still some px values left. Fixed. > - Names are used for color, where numbers should be used see: > http://www.w3.org/TR/WCAG10-CSS-TECHS/#style-color-contrast That's not what that guideline says. It shows you a *technique* to help you make sure that you can easily see that there's enough contrast by looking at the percentage/hex value, but that doesn't mean that there's anything magical about using hex/percentages over named colors. The few colors we use that named (gray and red on white) have plenty of contrast. Of course, when constructing an accessibility validator, it's easy to add a rule like that to trigger a warning, which is a good idea, since a lot of the named colors aren't good combinations (red on orange, etc). But in our case, we're OK. > - Text like Description and discreet could use a bit more contrast. OK, made them a little darker. Have a look now. > - Inline style elements are used, where classes should be used. Where? I couldn't see any when testing a couple of different templates. > - For printing an href="javascript.print()" is used. An alternative for non- > javascript users should be available. It's called the "print" menu entry in your browser. ;) If you want, we can avoid rendering this link if you don't have JS enabled ? but I have removed it altogether from the default layout, and let it be up to the integrator to enable this viewlet again, since print / send to are of questionable value. It's a requirement that used to be common in RFPs etc, but seems to be eschewed in favor of Facebook/Twitter buttons these days ? which are equally annoying and not used by anyone ? statistically speaking ? either. It mostly means "we are hip to social media" these days, and is mostly present on sites that aren't. Can you tell I don't like them? ;) > - sup tags are used where css should be used. Sub and sup can only be used > if the meaning of the content is different not for presentation's sake. see: > http://dev.w3.org/html5/spec/Overview.html#the-sub-and-sup-elements The registered trademark symbol is supposed to be superscript, do you see any other use that conflicts with this? > - h1 - h6 tags should be used for document structure and no levels should be > skipped. Like the current theme this theme also uses h5 tags without using h2 > till h4. My goal was to change as little as possible of the existing markup. If we introduce new tags for the h5s, we might break existing themes. I'm happy to make this change in Plone 5 where we are doing more significant markup changes, but I don't think it's worth being purist about it at this point. > - Even more so then the current theme the contentview tabs and the formtabs > look the same. Contentview tabs make you 'leave' the current page and the > formtabs keep you on the same page. This is confusing for users to see > different behavior for controls who look the same. I'll beg to differ, sorry ? they do the same thing, show aspects of a content type, the fact that some reload and some don't is a different issue. They are trying to express the same concept, and while the implementation isn't ideal, they are expressing the same kind of grouping (although on different levels). We're getting rid of these in Plone 5, so they will be short-lived anyway. Nobody really wants two levels of tabs. :) > - The PLIP states: "Keep the theme color-neutral (black, white, grays)" but I > see green and blue are used which are not color-neutral. Some colors are non-negotiable ? you need blue links, and I reused the same blue for the global navigation (just inverted). There's a lot of documentation that talks about "the green bar", so in the interest of keeping things simple, I added that color too. Those are the two only colors, and they are trivial to change, and examples of how to do it are provided in ploneCustom.css. The point of the statement was to address all the other use of color, which makes it hard to theme Plone to a particular visual profile. The two colors used now can be changed by uncommenting two new values in ploneCustom.css, and nothing else will conflict with a given corporate visual profile. > - Building the theme using html 5 seems like a good idea but it does generate > some issues: > > - The html doesn't validate. See earlier comments. 0 errors if you set it to be HTML5. :) > - Since older browsers don't support the html 5 tags the html needs to contain > both the html 5 tags and the 'old' div tags making the html a lot less > clean. The markup is pretty messy already, but I don't think we should try to fix this until Plone 5 to keep things simple for existing themes. > - Only the main template is updated using html 5 tags. All other pages, > viewlets, portlets etc don't use the html 5 tag which leads to > inconsistancy. Not sure what you mean here ? the portlets are already wrapped in the