[Grok-dev] CMS Project

[Matt Bowen]

Hey all,

Thanks for all the excellent feedback! I really appreciate your time and
insights. Please keep it coming :)

To reply to a few points:

On Dec 11, 2007 8:37 AM, Sebastian Ware <sebastian at urbantalk.se> wrote:

> My penny... everybody who can creates a CMS at some point... how about
> creating a CMS-construction kit where configuration and modifications
> are done in code. Some components are allready available.
>

I'd put money on you being right about everyone developing a CMS; eventually
it's just too tempting or feels too necessary. And a "CMS Construction Kit"
is a cool idea; however, I think developing a very basic, "minimal" CMS can
become (or at least inform) such a kit, if done correctly -- as long as
generally reusable parts are written to be reused, there's no reason those
parts couldn't be used in non ConCave projects. Using Peter's example, I'm
not sure why we wouldn't develop our document type to be reusable outside of
the project; the component architecture encourages that. However, I am wary
of trying to design an all-purpose CMS framework; it may be my level of
expertise, but I don't trust myself not to over engineer it. I hope trying
to develop a well thought out minimal CMS implementation can protect from
that, somewhat.


On Dec 11, 2007 9:18 AM, Kamon Ayeva <kamon.ayeva at gmail.com> wrote:
<snip>

If it was doable with Deliverance, we may have less to reinvent, and it
> would be ready for the future ?
>
>
The current plan is to use Deliverance for site theming and then generate
our own XHTML with minimal theming for actual content management components.
I think this will make the common case of theming (e.g., branding the site)
easier, but will add complexity to people who want to change absolutely
everything (because there are two layers to learn). To me, this is
acceptable, but it is a trade off.

>
>
> > 3. Data is easy to port to Plone portal types
> >
>
> Could be possible if the content types technology itself is shared between
> Plone and Grok. There were discussions here and in the Plone community about
> this kind of convergence. That would be a huge win to have to write the
> content class code once and deploy either on Grok or Plone.


That's kinda my hope, although I wouldn't be heart broken if I had to write
a script that simple takes a concave document and maps it into a ATDocument
on migration. The more interesting approach to me is to create our own
content types and then see if there's some way to make them compatible in
Plone -- e.g, have concave.content define the schemata and basic
implementations, concave.app.content define the concave specific stuff (e.g.,
browser views, adapters for core parts of concave, etc), and then something
like concave.plone.app that does the same for Plone. How reasonable an
approach that is though, I'm not sure :) Any thoughts?

On Dec 11, 2007 8:51 AM, David Bain <david.bain at alteroo.com> wrote:
> <snip>
> If you make it possible to migrate TO the CMS e.g. from Joomla then you've
> got a winner, even better if it could somehow be made to use existing themes
> from other CMSes. Just dreaming :)
>

This would be really, really awesome, but also really, really hard in some
cases. If we have reasonable blog and comment support, moving from something
like Wordpress or Typepad to whatever we make should be doable; the content
types wouldn't be fundamentally too different. However, having migrated
drupal sites before, I know mapping their content types to other systems
required human analysis -- then again, Drupal is a much more
general/powerful CMS than I have in mind, so that's an unlikely move anyway.
So, it'll really depend on having people who want to offer that kind of
coding and picking which CMSes make sense to support migrations from. It
would totally be a win though -- it would make it much easier for people to
evaluate the system in terms of what they already know.

Thanks all,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20071211/c0de7379/attachment.htm