Re: [Framework-Team] Re: Plone 4 dependencies
On 01.06.2009, at 21:42, Hanno Schlichting wrote: I think we can move all the admin-UI stuff like preference screens, folder_copy, object_rename and author pages and the like from CMFPlone to browser views in Plone 4, as these tend not to be customized that often. +1 also, those views contain more functionality than the ones mentioned below and thus the benefit of migrating those rather sooner than later is a lot bigger. IMHO those changes are definitely plone 4 material. cheers, tom I wouldn't want to see document_view, folder_listing and the more commonly customized templates to be changed in Plone 4, though. Changing these will break lots of customizations out there and I only want to do that once we have figured out the complete story for TTW editing and new-style default theming. As long as we have Archetypes and any AT-based add-on, we won't be able to ditch portal_skins anyways. It's whole widget machinery and base_* are too tightly based on nested skin layers and lots of magic. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
On May 30, 2009, at 3:01 PM, Matthew Wilkes wrote: On 30 May 2009, at 22:23, David Glick wrote: Raphael raised a question about the consequences of backwards- incompatible changes for add-on developers. Switching to a newer Zope and CMF will indeed probably have some consequences. But this is a major version bump of Plone, so I think it's okay if some things change; this is probably our best opportunity to rip out some old cruft. Perhaps the question we should be asking is, "What do we want the new features for Plone 5 to be?". I think moving to browser views for default templates would be useful, if not just so it unifies our customisation story. We've got lots of new things that we're all itching to use, but we need to balance that with making the upgrade from 3->4->5 as smooth as possible for our integrators. On the concrete example given, quite high-up on my list of wishlist features for Plone 4 would be ditching portal_skins and having a layer-aware analogue for browser views, with an exporter. TTW editing is sorely missing in 3.x, and I think it's a pain point. I absolutely agree that we need to do this. (See my blog post [1] from February and the follow-up e-mail conversation [2] on how I think we should go about it.) Given that the goal of the Plone 4 release is to incorporate fairly low-risk things that have already been built, though, I'm not sure this is an appropriate goal for Plone 4. And while I agree that in the end view templates should be browser views, I don't want to make that switch until we have a complete TTW editing story for browser views. I think this is the point you were making as well. If we start actually working on this and make rapid progress, and have a solid migration story, I'm willing to reconsider for Plone 4. [1] http://david.wglick.org/2009/report-from-the-berlinale-sprint-how-we-can-fix-the-plone-skin-situation/ [2] http://n2.nabble.com/Re:-report-from-the-Berlinale-sprint:-how-we-can-fix-the-Plone-skin-situation-td2376181.html David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidgl...@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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
On 30 May 2009, at 22:23, David Glick wrote: Raphael raised a question about the consequences of backwards- incompatible changes for add-on developers. Switching to a newer Zope and CMF will indeed probably have some consequences. But this is a major version bump of Plone, so I think it's okay if some things change; this is probably our best opportunity to rip out some old cruft. Perhaps the question we should be asking is, "What do we want the new features for Plone 5 to be?". I think moving to browser views for default templates would be useful, if not just so it unifies our customisation story. We've got lots of new things that we're all itching to use, but we need to balance that with making the upgrade from 3->4->5 as smooth as possible for our integrators. On the concrete example given, quite high-up on my list of wishlist features for Plone 4 would be ditching portal_skins and having a layer- aware analogue for browser views, with an exporter. TTW editing is sorely missing in 3.x, and I think it's a pain point. Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
On May 27, 2009, at 1:47 PM, Matthew Wilkes wrote: On 26 May 2009, at 10:59, Hanno Schlichting wrote: I think someone has to try and see what kind of changes are acutally required to make a current Plone 3.3rc3 run on Zope 2.12 or even better a real client side with a collection of add-ons. I doubt it's very hard, a concerted effort by me and Sidnei at the last Summer of Code summit left us with Plone trunk working on Zope trunk, and that was only a few weeks after the conference. Zope really was where most of the changes needed to be, I do think targeting 4.0 to Zope 2.12 is feasible and proper. +1. The nice thing is that the question of what changes need to happen to support Zope 2.12 and CMF 2.2 is not some big unknown. We already have changesets that take care of the vast majority of the issues, thanks to the work Hanno, Matthew, Laurence and others have been doing on Plone trunk over the past year. That's not to say that it wouldn't take some work. The desirable changesets that take care of Python 2.6 compatibility, removing old Zope 2-style interfaces, and miscellaneous non-risky improvements are mixed in with things like moving the default content views to be browser views in ATContentTypes instead of skin layer templates in CMFPlone, which probably need some more discussion and may or may not be wanted in Plone 4. My gut feeling is that we probably should target Zope 2.12 and CMF 2.2, and probably want a majority of the changes from Plone trunk, but will want to opt out of some that are overly ambitious or ripping out things that we don't have adequate replacements for yet. So I think it's probably time to create a new copy of the 3.3 branch for Plone 4, and start selectively merging changes from trunk. (Yes, this means that developers will have to start merging changes to 2 different branches aside from where they originally patched a bug. This is an unfortunate side effect of us working so far ahead. We'll also have to consider what happens with the version numbers of the various plone.* packages which Hanno has been calling 2.x for use with Plone trunk...in most cases the changes are probably fine for Plone 4 and we can just keep using 2.x, but if there is a package with some changes on trunk that we don't want, we'll have to make a 2.x branch without the undesirable change and move that package's trunk up to 3.x) Eric Steele, you should feel free to jump in and start being benevolently dictatorial. :) Raphael raised a question about the consequences of backwards- incompatible changes for add-on developers. Switching to a newer Zope and CMF will indeed probably have some consequences. But this is a major version bump of Plone, so I think it's okay if some things change; this is probably our best opportunity to rip out some old cruft. We do need to do a better job than we have in the past of documenting changes in a form that is useful to add-on developers trying to figure out why their product broke or what the new way to do something is. Creating a list of these changes is a task that should be done as changesets are reviewed and merged from trunk. David Glick Web Developer ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidgl...@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 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
On Wed, May 27, 2009 at 22:47, Matthew Wilkes wrote: > > On 26 May 2009, at 10:59, Hanno Schlichting wrote: > > I think someone has to try and see what kind of changes are acutally >> required to make a current Plone 3.3rc3 run on Zope 2.12 or even better >> a real client side with a collection of add-ons. >> > > I doubt it's very hard, a concerted effort by me and Sidnei at the last > Summer of Code summit left us with Plone trunk working on Zope trunk, and > that was only a few weeks after the conference. Zope really was where most > of the changes needed to be, I do think targeting 4.0 to Zope 2.12 is > feasible and proper. > +1 Andreas ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
On 26 May 2009, at 10:59, Hanno Schlichting wrote: I think someone has to try and see what kind of changes are acutally required to make a current Plone 3.3rc3 run on Zope 2.12 or even better a real client side with a collection of add-ons. I doubt it's very hard, a concerted effort by me and Sidnei at the last Summer of Code summit left us with Plone trunk working on Zope trunk, and that was only a few weeks after the conference. Zope really was where most of the changes needed to be, I do think targeting 4.0 to Zope 2.12 is feasible and proper. Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
