I've started wondering about porting a subset of Plone to Pyramid. Pylons has long lacked a full-featured CMS package. While Plone can be mounted as a sub-URL or vice-versa, it's still really big and different and harder to extend. As a programmer I'd be interested in making custom Plone products for my site, but the learning curve of doing that, plus adjusting the site templates, plus figuring out where in ZODB your data is stored in case you want to extract it later -- is daunting enough that my own website (Cheetah-built static) has been languishing unimproved for three years -- and I keep not writing blog entries or posting photos because I'm tired of the clunky old software.
So my choice has been (A) use Plone, or (B) build my own CMS. But Plone is so big, and so different from my normal Pylons work. As for building my own CMS, Plone has hundreds of expert programmers, user interface designers, and CMS specialists behind it -- I can't possibly make something a tenth as good. But if some Plone experts are willing to help, we could identify the minimum design requirements for a basic Plone-like CMS, and how to make it scalable so that more features can be borrowed from Plone later. I'm not sure how much Plone code can be borrowed directly, vs how much would have to be reimplemented. I'm looking for something in the Pyramid/Pylons spirit, without too much large Zopisms. So maybe stick with ZODB but don't take the whole kit and keboodle. Every part of the database should be documented, so that the data is easily extractable. Maybe these docs already exist for Plone/Zope, but finding them and distinguishing between relevant vs irrelevant docs is a big task for a newbie.
My vision is a basic page editor supporting HTML, ReST, TinyMCE and other formats. Versioning between "unfinished", "published", and "next version". (Full history would be nice but not strictly necessary.) Arbitrary URL hierarchy (sections, subsections). A default set of page attributes with a form, and a way to extend it. (E.g., for specific types of documents like book reviews, which would have additional attributes.) A comments system. A simple but scalable auth system. Bulk import of a static site. Multiple-sized image thumbnails. A UI something like the Plone tabbed UI. Those are the main features I'd be looking for in the first phases.
This could be a first big project for Pyramid if it's feasable. Anybody want to help design the specs and identify the resources?
We've actually had two in-person sprints on it, but it's a large job and not much was produced, at least not much that is very consumable by a "civilian".
I think it would be useful to concentrate on some sort of "repository" in which to store content first (as most everything else depends on having some normalized way to store and query content). We actually have tentative committments from some existing Plone folks to do a sprint by years end on that topic. Some spike code is here:
On Fri, 2010-11-05 at 14:58 -0700, Mike Orr wrote: > I've started wondering about porting a subset of Plone to Pyramid. > Pylons has long lacked a full-featured CMS package. While Plone can be > mounted as a sub-URL or vice-versa, it's still really big and > different and harder to extend. As a programmer I'd be interested in > making custom Plone products for my site, but the learning curve of > doing that, plus adjusting the site templates, plus figuring out where > in ZODB your data is stored in case you want to extract it later -- is > daunting enough that my own website (Cheetah-built static) has been > languishing unimproved for three years -- and I keep not writing blog > entries or posting photos because I'm tired of the clunky old > software.
> So my choice has been (A) use Plone, or (B) build my own CMS. But > Plone is so big, and so different from my normal Pylons work. As for > building my own CMS, Plone has hundreds of expert programmers, user > interface designers, and CMS specialists behind it -- I can't possibly > make something a tenth as good. But if some Plone experts are willing > to help, we could identify the minimum design requirements for a basic > Plone-like CMS, and how to make it scalable so that more features can > be borrowed from Plone later. I'm not sure how much Plone code can be > borrowed directly, vs how much would have to be reimplemented. I'm > looking for something in the Pyramid/Pylons spirit, without too much > large Zopisms. So maybe stick with ZODB but don't take the whole kit > and keboodle. Every part of the database should be documented, so that > the data is easily extractable. Maybe these docs already exist for > Plone/Zope, but finding them and distinguishing between relevant vs > irrelevant docs is a big task for a newbie.
> My vision is a basic page editor supporting HTML, ReST, TinyMCE and > other formats. Versioning between "unfinished", "published", and "next > version". (Full history would be nice but not strictly necessary.) > Arbitrary URL hierarchy (sections, subsections). A default set of page > attributes with a form, and a way to extend it. (E.g., for specific > types of documents like book reviews, which would have additional > attributes.) A comments system. A simple but scalable auth system. > Bulk import of a static site. Multiple-sized image thumbnails. A UI > something like the Plone tabbed UI. Those are the main features I'd be > looking for in the first phases.
> This could be a first big project for Pyramid if it's feasable. > Anybody want to help design the specs and identify the resources?
> We've actually had two in-person sprints on it, but it's a large job and > not much was produced, at least not much that is very consumable by a > "civilian".
> I think it would be useful to concentrate on some sort of "repository" > in which to store content first (as most everything else depends on > having some normalized way to store and query content). We actually > have tentative committments from some existing Plone folks to do a > sprint by years end on that topic. Some spike code is here:
> I'll keep you notified about sprint timing and such, as I hear of it.
> - C
> On Fri, 2010-11-05 at 14:58 -0700, Mike Orr wrote: >> I've started wondering about porting a subset of Plone to Pyramid. >> Pylons has long lacked a full-featured CMS package. While Plone can be >> mounted as a sub-URL or vice-versa, it's still really big and >> different and harder to extend. As a programmer I'd be interested in >> making custom Plone products for my site, but the learning curve of >> doing that, plus adjusting the site templates, plus figuring out where >> in ZODB your data is stored in case you want to extract it later -- is >> daunting enough that my own website (Cheetah-built static) has been >> languishing unimproved for three years -- and I keep not writing blog >> entries or posting photos because I'm tired of the clunky old >> software.
>> So my choice has been (A) use Plone, or (B) build my own CMS. But >> Plone is so big, and so different from my normal Pylons work. As for >> building my own CMS, Plone has hundreds of expert programmers, user >> interface designers, and CMS specialists behind it -- I can't possibly >> make something a tenth as good. But if some Plone experts are willing >> to help, we could identify the minimum design requirements for a basic >> Plone-like CMS, and how to make it scalable so that more features can >> be borrowed from Plone later. I'm not sure how much Plone code can be >> borrowed directly, vs how much would have to be reimplemented. I'm >> looking for something in the Pyramid/Pylons spirit, without too much >> large Zopisms. So maybe stick with ZODB but don't take the whole kit >> and keboodle. Every part of the database should be documented, so that >> the data is easily extractable. Maybe these docs already exist for >> Plone/Zope, but finding them and distinguishing between relevant vs >> irrelevant docs is a big task for a newbie.
>> My vision is a basic page editor supporting HTML, ReST, TinyMCE and >> other formats. Versioning between "unfinished", "published", and "next >> version". (Full history would be nice but not strictly necessary.) >> Arbitrary URL hierarchy (sections, subsections). A default set of page >> attributes with a form, and a way to extend it. (E.g., for specific >> types of documents like book reviews, which would have additional >> attributes.) A comments system. A simple but scalable auth system. >> Bulk import of a static site. Multiple-sized image thumbnails. A UI >> something like the Plone tabbed UI. Those are the main features I'd be >> looking for in the first phases.
>> This could be a first big project for Pyramid if it's feasable. >> Anybody want to help design the specs and identify the resources?
