Hey all,<br><br>Thanks for all the excellent feedback! I really appreciate your time and insights. Please keep it coming :)<br><br>To reply to a few points:<br><br>On Dec 11, 2007 8:37 AM, Sebastian Ware <<a href="mailto:sebastian@urbantalk.se">
sebastian@urbantalk.se</a>> wrote:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">My penny... everybody who can creates a CMS at some point... how about
<br>creating a CMS-construction kit where configuration and modifications<br>are done in code. Some components are allready available.<br></blockquote><div><br>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.
<br><br><br>On Dec 11, 2007 9:18 AM, Kamon Ayeva <<a href="mailto:kamon.ayeva@gmail.com">kamon.ayeva@gmail.com</a>> wrote:<br><snip><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<div>If it was doable with Deliverance, we may have less to reinvent, and it would be ready for the future ?<br> </div></blockquote><div>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.<br></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
<div><br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>3. Data is easy to port to Plone portal types<br></blockquote></div><br>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.
</blockquote><div><br>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?<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
On Dec 11, 2007 8:51 AM, David Bain <<a href="mailto:david.bain@alteroo.com">david.bain@alteroo.com</a>> wrote:<br><snip><br>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 :)<br></blockquote><div><br>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.
<br><br>Thanks all,<br>Matt<br></div></div></div>