I'm actually in the process of trying to port my old Joomla (that's php, folks!) site to something in Pylons...for my purposes of not losing too much content I was trying to use a vaguely similar db schema so I could export data & still have it be useful in the new app...(I'll let you know if I get anywhere...)
Bottom line is you'll need at least this: - content (eg articles, etc) - media (images, audio, video, etc) - an organisational hierachy (such as sections & categories) - templates In terms of functionality, Joomla uses an interesting concept called components, which all go into a common "components" folder, & which can be downloaded from a repository as a .zip file. You just upload the .zip file to the CMS, & it installs the code file, & creates DB tables if necessary. That way, non-tech users can add functionality to their site with a one click process, which makes it easier for users. It also has a separate administration folder, so any admin screens code can be kept together, making it easier to force SSL for your content admin section, without requiring it for the public front-end section of your CMS app... Cheers, Bruce Coble On Nov 15, 6:29 am, Mike Orr <sluggos...@gmail.com> wrote: > On Sun, Nov 14, 2010 at 8:10 AM, Leon <leont...@gmail.com> wrote: > > 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. > > You bring up some good ideas, and my response is "Let's do both." Port > Plone and design another CMS. This isn't about the limits of Plone. I > haven't heard anything about reaching them. This is about Pylons > developers not having a CMS unless they install the whole Zope/Plone > package and set up a WSGI child app and then have to learn and > maintain two different environments, or to leave Pylons behind and do > everything in Zope, making Zope products for their site features, > which is again a large learning curve and not what they really wanted > to do. > > Plone is not just any CMS. It's the premier open-source CMS, the one > which has brought the words "open-source" and "Python" to the kinds of > suits that normally consider only commercial products. It did this by > having features that match (and in some cases exceed) programs costing > $30,000. Plone has more developers than all the other Python web > frameworks combined. The home page says "340 core developers and more > than 300 solution providers [consultants] in 57 countries". Plus a lot > of people making Plone products [add-ons]. They have brought in a lot > of experts in CMS design, usability, accessibility, etc. That is what > I want to leverage, either their experts themselves or the decisions > their experts have made. I tried to make a CMS on my own it would be > crap and non-scalable and have like two other users, and it wouldn't > be able to use any of the add-ons that have been made for Plone. > > > 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? > > An application component like a CMS is necessarily opinionated, so > that's not an issue. > > There are four or five approaches. I've been discussing this with > Plone developers, and Plone is essentially a Zope product, so if we > solve the general problem of running Zope products in Pyramid, we've > solved the problem of Plone. That would have other benefits because > people might find other Zope products useful, or be willing to use BFG > because it has a documented way to run Zope products (which other > non-Zope framework has that :). The Grok developers may be able to > advise us. I think this would require importing a large part of the > Zope runtime, so the question would be how much. ZODB would be > necessary to avoid restructuring the database. But would we need > Zope's visual db inspector (the admin interface)? Maybe not. > > Another approach would be to port part of Plone without most of Zope, > but I'm not sure how feasable that is. > > Another approach would be to mimic the user interface and workflow and > API, borrowing any pieces we can and reimplementing the rest. That is > what I was originally thinking, and it's also what Leon is more or > less suggesting: a new CMS based on the most successful ones. Although > Leon suggests basing it on Drupal. > > One way or the other it would be useful. Using Plone currently > requires doing everything in the Zope universe. Using Drupal means > using PHP. Both cases require leaving behind everything we like about > Pylons. So there is certainly a need for a CMS like those, and even a > simpler one would fulfill the needs of many smaller sites. > > > I would say that Turbogears approach is rather nice where the > > supposedly higher-level CMS is just a blessed opinion of separate > > components. > > It would be great if the TG developers joined on, but outside that, I > don't necessarily want to commit to all the other choices TG has made. > Also, there is no TG API for Pyramid yet. If TG does decide to join > Pyramid, it will have to make some fundamental decisions like whether > to stick with @expose or go to @action, which does most of the same > things but in a different way. We really need TG/Pyramid to exist > before we can think about using it for a CMS. > > > 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: > > That's great, that's the kind of expertise we need around. > > I was going to start a Plone-pyramid list, but Leon's message is > making me thing a Pyramid-cms list might be better. > > -- > Mike Orr <sluggos...@gmail.com> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-disc...@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
