Hi all, (I've been passively reading the list for a few months and this is my first post, so apologies if it does not fit somehow.)
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? 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. I would say that Turbogears approach is rather nice where the supposedly higher-level CMS is just a blessed opinion of separate components. Here the job of the CMS is to ensure interoperability among the components by setting protocols (eg. standardize event types?), and having an opinion about components or interfaces so that they become more cohesive (then developers won't need to support 100 form generation frameworks and 1000 user authentication framework for his/her single plugin). 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: * Centralization of extensions, community, documentation, etc. Extension/module developers can create and account at drupal.org and push their source there for the public to see. Each drupal installation can also optionally "ping home" to send drupal.org some module usage data -- which is super useful in selecting what modules to use in your website. They also harmonize the license for contributed modules, which may benefit certain users. The community in general is also proactive IMO in merging similarly scoped modules wherever possible and discourages duplication of features. * Good module dependency handling, which may be already done by setuptools here. (The CMS needs to give its opinion about the dependency framework it is using, and also perhaps provide a UI for enabling/disabling modules.) * Drupal has framework for creating lists, messaging, managing fields in posts... but none are in core (version 6) -- they are all separate contributed modules that people find useful, so they adapt and extend them. In a sense the modules have their own public APIs and just by being published in drupal.org, people with similar requirements will find and extend them instead of reinventing the wheel. Then what I think are the bad things: * Breaking compatibility among major versions. Because Drupal is so big and they are innovative about improving general architecture, major versions get massive overhaul. Maybe like the UI of MS Office 2003 vs 2007 except it happens every 0.5 - 1 year (sorry I can't get an analogy closer to your heart). Good for development speed... but maybe not good for enterprises (but Drupal can survive that just fine). They do document the changes very clearly though, where you can get an idea how horrible it is to upgrade: http://drupal.org/node/224333 . With good dependency handling like setuptools, maybe the CMS can have "rolling releases" like Arch Linux <https://bbs.archlinux.org/ viewtopic.php?id=18063>. On Nov 14, 2:56 am, Jens Hoffrichter <[email protected]> wrote: > Hello everyone, > > The thought of having a CMS on top of Pylons/Pyramid didn't leave me alone, > and I caught myself thinking about how I would implement it, so I'm going to > throw some ideas and thoughts in the room, and hope a productive discussion > spawns from it. > > First of all, I have a heave CMS background, though mostly in the TYPO3 > world. Recently, we implemented a big site using Drupal, utilizing a Pylons > management service (to edit all the data and stuff like that), so I have > some decent knowledge in those two CMS. I have never worked with Plone, > except from taking a look at it once or twice to see if it would be suitable > for us, so I can't say anything about it on an architectural level, or how > to really use it. > > In addition, I'm up to my ears in a huge TYPO3 project, so if I start > talking or suggesting to many TYPO3ish things, just start hitting me over > the head with a blunt object ;) > > On the other hand, TYPO3 is one of the very few CMS I know where you can > implement a page and give the editors the possibilities to layout a page > exactly how they want it, without any HTML coding, with teasers how they > need it, just point and click. So it isn't all bad, but without doubt, TYPO3 > is a behemoth, and something a lot simpler would probably be better. > > In my opinion, what would be needed for a simple CMS: > > - Templating (borrowing from Drupal):In Drupal, you define a page template > with regions, like left column, right column, main content, footer, > whatever, and configure in the backend which modules or menus are rendered > in which order in a certain region. That would probably be sufficient in the > beginning, although I really would like the possibility to override which > modules are rendered on a given page/path in a way more intuitive than in > Drupal. From an extension/module, you just return the inner html from the > content area, and the templating system inserts that in the given region. > This would be a nice thing to have anyway, imo, instead of inheriting > templates the standard Mako way. I'm not sure if there is an easy way to > accomplish this, but that would be a neat thing. > > - Menu system (borrowing from Drupal): In Drupal, you can define an > arbitrary number of menus, with entries as many as you like, and render them > in certain regions of the page. The menus are simply a mapping of a URL to a > name in a tree. My vision would be to allow the menu system to create links > to routes as you like, so you can simply use any controller in a menu, > making the thing really extensible and powerful. And in the end of the > normal routing, a catch all route would be, which would try to resolve the > URL to any dynamic content, e.g. from the page module (see below) > > - Page module (not really sure where this comes from, probably from Drupal, > too): The first step would be to have a simple page module, where you can > enter a title, a body text with a rich text editor, and a couple of meta > information, maybe like author and creation timestamp, and if it is public > or not. The content repository (for a lack of a better name) should store on > which URL this content is entered, which extension is responsible for > rendering the content, and delegate the rendering to that module > > To upgrade that along the path shouldn't be too hard, maybe some other > content entry extensions or so.... > > I'm realizing by now that I would be borrowing really a lot from Drupal, as > it is a really good CMS, the only thing which isn't that great is the easy > formatting of pages with teaser like content, and that there is no > distinction between the front end and the backend. And that it is PHP, of > course :-P > > The lacking distinction between frontend and backend really bit us in the > butt at our last project, as we wanted to upgrade the used jquery libraries, > which just wasn't possible, as the Drupal content modules depend on a > specific version of jquery and jquery-ui, and that isn't the best way, imo. > > And for the content formatting could be implemented in a different frontend > rendering module, which shouldn't be that hard. (I'm seeing something like > TemplaVoila here, which is one of the most useful pieces for TYPO3 out > there). > > But a lot of other stuff is great, like the hook system Drupal provides, or > the frontend user management, and the form rendering isn't too shabby, too. > > But I personally thing, that those components would give a good start into a > CMS project on top of Pylons/Pyramid. > > I'm just thinking out aloud here, if other people have different ideas, I > would be glad to hear them, maybe I'm on a completely wrong track here. But > I think something simple for static pages, and have the other, dynamic stuff > being rendered by normal controllers, would be definitely enough for a > start. > > Cheers, > Jens -- 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.
