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?
Replies to pylons-devel.
--
Mike Orr <slugg...@gmail.com>
http://lists.repoze.org/pipermail/cmf3k/
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:
http://svn.repoze.org/repoze.itory/trunk/
I'll keep you notified about sprint timing and such, as I hear of it.
- C
A