On Sun, Nov 14, 2010 at 8:10 AM, Leon <[email protected]> wrote: > Another thing is that if the project is successful, due to it being > written in Python and based on pyramid, I think a lot of Plone > developers that find Plone already reaching its limit will migrate to > the new CMS, just like some Zope developers that migrated to > repoze.bfg. If the fresh ideas are good, people will flock in to > possibly the only alternative that still inspires partly from Plone.
You bring up some good ideas, and my response is "Let's do both." Port Plone and design another CMS. This isn't about the limits of Plone. I haven't heard anything about reaching them. This is about Pylons developers not having a CMS unless they install the whole Zope/Plone package and set up a WSGI child app and then have to learn and maintain two different environments, or to leave Pylons behind and do everything in Zope, making Zope products for their site features, which is again a large learning curve and not what they really wanted to do. Plone is not just any CMS. It's the premier open-source CMS, the one which has brought the words "open-source" and "Python" to the kinds of suits that normally consider only commercial products. It did this by having features that match (and in some cases exceed) programs costing $30,000. Plone has more developers than all the other Python web frameworks combined. The home page says "340 core developers and more than 300 solution providers [consultants] in 57 countries". Plus a lot of people making Plone products [add-ons]. They have brought in a lot of experts in CMS design, usability, accessibility, etc. That is what I want to leverage, either their experts themselves or the decisions their experts have made. I tried to make a CMS on my own it would be crap and non-scalable and have like two other users, and it wouldn't be able to use any of the add-ons that have been made for Plone. > I don't have any experience in Plone but I think rather than porting > Plone, it would be better to create a distinct/new CMS that takes the > good things from multiple frameworks instead of just porting Plone. > That is, "reinventing" Plone just like repoze.bfg reinvented Zope (I > don't know about Zope, but surely repoze.bfg took good parts of it > (plus good parts from Rails, Pylons 1, whatever) and threw away the > bad things). (this is your choice B.) > > Because I don't know Zope I don't know how much can be ported from > Plone and be rebased to pyramid / repoze.bfg, but I really think that > it won't be a lot. Especially if you want to still embrace the Pylons > philosophy of non-opinionation somewhat. Also, if you embrace Plone > too much, then isn't that the same Plone but with pyramid backend + > Zope dependencies? An application component like a CMS is necessarily opinionated, so that's not an issue. There are four or five approaches. I've been discussing this with Plone developers, and Plone is essentially a Zope product, so if we solve the general problem of running Zope products in Pyramid, we've solved the problem of Plone. That would have other benefits because people might find other Zope products useful, or be willing to use BFG because it has a documented way to run Zope products (which other non-Zope framework has that :). The Grok developers may be able to advise us. I think this would require importing a large part of the Zope runtime, so the question would be how much. ZODB would be necessary to avoid restructuring the database. But would we need Zope's visual db inspector (the admin interface)? Maybe not. Another approach would be to port part of Plone without most of Zope, but I'm not sure how feasable that is. Another approach would be to mimic the user interface and workflow and API, borrowing any pieces we can and reimplementing the rest. That is what I was originally thinking, and it's also what Leon is more or less suggesting: a new CMS based on the most successful ones. Although Leon suggests basing it on Drupal. One way or the other it would be useful. Using Plone currently requires doing everything in the Zope universe. Using Drupal means using PHP. Both cases require leaving behind everything we like about Pylons. So there is certainly a need for a CMS like those, and even a simpler one would fulfill the needs of many smaller sites. > I would say that Turbogears approach is rather nice where the > supposedly higher-level CMS is just a blessed opinion of separate > components. It would be great if the TG developers joined on, but outside that, I don't necessarily want to commit to all the other choices TG has made. Also, there is no TG API for Pyramid yet. If TG does decide to join Pyramid, it will have to make some fundamental decisions like whether to stick with @expose or go to @action, which does most of the same things but in a different way. We really need TG/Pyramid to exist before we can think about using it for a CMS. > I have quite an experience with Drupal extension/module API so let me > add on what I think are the good things that Pylons can take example > of: That's great, that's the kind of expertise we need around. I was going to start a Plone-pyramid list, but Leon's message is making me thing a Pyramid-cms list might be better. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
