On Sat, Jun 20, 2009 at 12:17 PM, Martin Aspeli<optilude+li...@gmail.com> wrote: >> - c20188, c20190, c23197 — removal of PloneFolder (hannosch) — need to >> double check whether this requires a migration for any persistent objects, >> and write that if necessary > > +0 to remove.
There's no persistent stuff based on that particular class since Plone 2.1. What is still left is the OrderedContainer implementation inside the PloneFolder module, as this is used by the PloneSite object itself. This ought to be cleaned up since OFS has almost the same implementation, but this is a different task. The temporary folder used for the FactoryTool was based on this as well, but can use the PortalFolder from CMF instead. It's just faking some more rich environment to create a new content object in and luckily never persisted. >> - c20337, c20338, c22979, c22981, c22988 - switch the control panel to be >> based on normal actions in a new action category, rather than using a >> special control panel tool (hannosch) — see also >> http://dev.plone.org/old/plone/ticket/8804 > > +0 - we need to make sure the existing controlpanel.xml import step > continues to work. There's an extra PLIP for this for Plone 5. Especially since I figured out that actions in their current form are the most critical performance bottleneck we have by a large margin, I don't want to move anything to actions at all anymore. I'd leave these changes out until we have figured out what to do with actions in general instead. Moving more actions to the actions tool will make things slower if we don't include some of the workarounds and hacks I did to the actions machinery all over. >> - c22831, c22832, c22891, c22951 — remove external editor (hannosch) — >> see http://dev.plone.org/old/plone/ticket/8592 > > -0 - people do use this. what's the cost of keeping it? See the ticket for details. It has an extra ticket and needs discussion, so better leave it out for now. The main argument is that it's unmaintained for ages and not used by many. It's a perfect add-on candidate. >> - c22847 — remove wicked from core (hannosch) — see >> http://dev.plone.org/old/plone/ticket/8593 (but note that as of this week >> Carsten Senger has been doing some maintenance...yay!) > > +0 to make this an add on people can install if they need it, but we should > endeavour to make it work for migrated sites This has an extra ticket as well and I'd leave it out of the other changes. There's at least documentation to be done here if we remove it from the core. >> - c23193 — turning default_error_message into a browser view (hannosch) — >> seems like a decent idea to me, but as implemented here it removes the >> redirector and content search features > > +0 - I think ideally plone.app.redirector should just override this view and > do nothing if not explicitly installed. I'm not sure we have time to do that > properly, though. I wouldn't touch this. The main reason for these changes are, that the old way of doing things doesn't work in the repoze.zope2 / WSGI world. Exception views, standard_error_message, the error_log and all that stuff simply doesn't work at all. So the whole of p.a.redirector needs to be changed quite a bit to be made to work in that new world. Since WSGI is out of the scope for 4.0, I'd leave these things out for now. >> - c23198, c23199 — removal of portal_interface tool (hannosch) — if we >> remove this then we lose the way to check for marker interfaces from >> action expressions, for instance. also, it's missing a migration > > +0 to remove. Doesn't plone.app.layout.globals have something for this > that's based on a view rather than a tool? I'd leave this in place, but then it needs to be changed to work with zope.interface interfaces instead of Interface stuff. Removing this was made under the assumption that there's no skin templates / scripts left in default Plone that would need this. This won't be the aim for Plone 4.0, so this thing might still have some legitimate use. >> - c23226, c23233 — moving migrations to plone.app.upgrade and using all >> GS without the migration tool (hannosch) — -0 from me...I think moving >> these to a separate package may actually make it harder to keep migrations >> in sync with the Plone release they belong too, simply from the standpoint >> of reviewing svn history > > +1 to move to all GS, at least. I don't have a strong feeling about the > package location. Maybe Hanno does? The initial driver for making this into its own package, was that the upgrade steps tend to have dependencies on quite a number of add-ons, like CMFEditions, KSS, portlets, ... for interfaces or to call into code to make some changes. If the Plone distribution itself contains the migration code, it gets all these dependencies pulled in and makes it quite hard to create a "minimal base distribution". The way I attacked the "unclutter dependencies / base distribution" problem is based on the assumption that the Plone distribution itself turns into a no-code, policy distribution of some kind in the end, so all code moves out of the package over time. Based on that direction it made sense to move the upgrade stuff out of the package, since I had to change and re-arrange it entirely anyways to match the new GenericSetup based approach. >> - c23337 — Removed strangely implemented users search from the users >> folder (hannosch) — I didn't look carefully enough yet to see whether this >> is a good idea or not :) > > Strangely implemented users search, ey? ;-) That's also known as the Members folder roster. This is part of removing all default content from the base installation. >> - c23343 - Removed initial content from default installation (hannosch) — >> This probably does belong in a profile in a separate package that is >> included by the standard installers. But creating that hasn't been done >> yet. > > -0 - I think Plone needs to ship with some default content. Where it lives I > don't care. <rant> Well, I really hate having default content around, that I have to delete all the time and people use in tests that later on break if we change it. The initial content just won't make sense for many sites and people waste huge amount of times to try to get the initial content to match some form of uber-use-case. Has anyone looked at how much time people spent of fixing the nested "past events" collection? Except that everyone really thinks that nested collections are a bad idea in general and they actually don't really work? And then we have the infamous "front-page" which welcomes our users to Plone 3.0 with the exact same message up until today? We don't update these things and there's no one driving it. I'd just rather have something be part of the installers that welcomes new users and points to some section on plone.org for continuously updated information. An updated guide on plone.org about "Your first steps with Plone - how to create content" and a "How to organize your content (simple information architecture)" stuff would be more helpful and allow users to feel in charge of the content in their site. Right now first time users can't really tell, if those initial folders are content or part of the application logic and won't dare to change them. Not to mention that they create hard problems in multi-lingual settings, where you actually want to layout your site quite differently. So +1 one a "welcome screen" that isn't content in itself but a big -100 on any content in a new site. That's what demo.plone.org would be for. </rant> >> - Consolidating the skin directories into just plone_browser, >> plone_resources, and plone_images....plus moving 3rd party javascripts to >> plone.app.javascript. — I'm -0 on this. Keeping the old layout would make >> it easier to merge things from the 3.x branch; switching to the new layout >> would make it easier to merge from trunk. Keeping the old layout has the >> advantage of not obsoleting a lot of existing documentation, and not >> changing something that we think there's a good chance we'll change again >> in 5.0 when we hopefully have a better unified Zope 3 vs. CMF skinning >> story. > > -0 - I agree with you. I think we should tackle this by getting rid of skins > altogether. :p Yep, this doesn't make sense until we remove all of them. I'll probably just revert those changes on trunk as well to make merging easier in the meantime. Once an entire folder is empty, we can remove it. >> - Archetypes c8430 — return unicode encoding by default (hannosch) — My >> charset and encoding fu is weak. Is this what we want? > > +1 to make Plone all unicode, all of the time. I defer to Hanno, though. There's quite a number of interesting implications with this, for example what is getting cataloged and if everything in the catalogs needs to be migrated, not to mention all code that had been written to deal with the current situation. For Plone 5 this makes perfect sense to do, for 4.0 this is a potential can of worms and I'd personally not try it. This change will avoid quite a number of Unicode errors in a lot of places where we need to explicitly deal with them right now. But it will introduce errors into places where we haven't seen them before. Given that we have almost no Unicode-driven test coverage for any functionality, these things will only be found by users and have quite a large potential bad marketing effect. I'd advise not to try this on a fixed and limited time schedule. >> - The current situation with regard to PlacelessTranslationService needs >> to be reviewed to make sure that our language negotiator and product i18n >> dirs are still getting registered properly following simplification/removal >> of Five's Zope2 i18n integration layer. Hanno said he could probably take >> a look at this. > > Let's hold him to that. ;) This should be quite simple, as I told David in a private mail already and I'm going to look into this. >> - I switched back to Zope 2.12.0b1 for now because with Zope 2.12.0b2 >> there is an issue preventing the Unauthorized error when you first try to >> access the ZMI from getting propagated into an HTTP authentication request. >> I haven't had time to dig into this yet although I did check a non-Plone >> Zope 2.12.0b2 and it didn't seem to be an issue there. > > Weird. Maybe to do with our force migration of the root acl_users to PAS? There's maybe something in the GRUF/PAS part that I changed to deal with this, which hasn't been adjusted yet. Exception handling is both very different in Python 2.6 (no string exceptions anymore) as well as repoze.zope2, so there might also be some kind of new problem. >> - We need to make plone.recipe.zope2instance work with an eggified zope. >> Currently it doesn't know where to find the mkzopeinstance script or other >> skeleton configuration. I made a quick hacky branch to make my dev >> buildout work, but this needs some more careful work. > > Do we? I thought we could basically get away without an instance at all (but > then where do we put 'Extensions' and 'import'?), just depending on the > right things and generating a zope.conf and a startup script? I haven't > looked into it, though. We need an instance of some sort to have a place for the zope.conf and site.zcml and start/stop script for one. Since we want to support ZEO and the http port of the webserver is in the zope.conf file, we need the ability to have multiple instances. Since we will need to change quite a bit of that stuff when WSGI hits, I'd rather try to mimic the current behavior / layout as closely as possibly for 4.0, so we don't invalidate the documentation twice. Hanno _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
