[haiku-web] Re: CMS

On 2006-03-22 at 11:49:41 [+0100], Waldemar Kornewald <wkornew@xxxxxxx> wrote:
> > It is also feature-complete and tried and tested. It can also be slow as a
> > pig under heavy load but there are ways of dealing with this.
> 
> Slow? It was unusable on my computer. That's why I hoped that it can be
> optimized. There seemed to be a few articles on the Plone website.
> Somehow, the site even slows down Firefox... :(

It shouldn't be slow on a single

> > The Plone guys have put a lot of effort into making it easy to work with
> > Plone. But you also have to consider the needs of the site maintainers and
> > in my experience none of the alternatives come close to Zope for add-ins
> > and stability. As I've said, you can use Mailboxer to integrate mailing
> > lists, XUF to hook up to external memberships. As it's sitting on a
> > full-blown application server you can write what's missing fairly easily.
> 
> But we can easily integrate all of that into Plone if we have to, right?

Yes, Plone is just a "skinning" of Zope + CMF.
 
> > I haven't looked at the competition for a while but apart from OpenCMS or
> > Typo3 I haven't heard of many systems that have enough developers around
> > them to ensure viability. I've been able to do everything I need with Zope
> > and I can only recommend a system that I would be prepared to work with.
> 
> OpenCMS and Typo3 were not intuitive enough for us.

Fine with me.
 
> > Just look at the add-ons you get for Zope/Plone:
> > http://plone.org/products
> 
> There even is a usability issues tracker...nah we have Trac. :)

They are heaps of Products but not all of them are or actively maintained.
 
> > From what I've read I think that the proposed site is similar to
> > http://www.dzug.org which uses Zope but not Plone.
> 
> Only at a basic level. The problems start when creating content. You
> must enter an ID (why should I care!?) and sometimes you must enter
> paths which I don't understand at all. Again, we would have to read the
> documentation in order to understand the CMS. That's not what I want.

What your looking at is the ZMI - which is for admins and programmers. All 
documents have to have IDs. Whether these are generated by the author or a 
computer is another matter. Zope's object structure is often quite helpful as 
it resembles a file system so it makes sense that the user assigns the names. 
On the other hand, I don't like putting content in the ZODB and it is easy 
enough to wrap something around the ID generation in a CMS interface. For 
simple stuff people cope quite well with the ZMI - a customer of mine writes 
the articles on p-portal using Zope and he has very little computer knowledge.
 

> Agreed. I've sorted everything by priority, now. Maybe that helps.

Should do.
 
> > I consider neither general internationalisation nor tight forum/e-mail
> > integration to be mission critical. You might want to have a few articles
> > in different languages but that doesn't need a full multilingual CMS. 
> > Forum
> > / e-mail integration requires a common storage system which is kind of
> > difficult if the mailing lists are hosted elsewhere. However, there is a
> > Zope Product which stores e-mail in an external RDBMS but I think it's 
> > fine
> > to run Mailboxer next to zForum and just tell the catalog to search both.
> 
> Internationalization can be very simple, but it is important to reach
> new markets. When you switch the language it must not mix with English
> content.

Yes and no - I don't like things offering to switch between languages on a 
single page but if you only have a subsection of content in a particular 
language then it needs to be made clear. For the time being English is a sine 
qua non for Haiku developers who are the most important customers of a site.

> Forum+email integration is not very important. I think that it would
> even be acceptable to host the mailing lists, ourselves if we can get
> it, but we can as well just clean up our forum and not have forums *and*
> mailing lists about the same topics.

We can host the mailing lists assuming someone can maintain them. Of course, 
migrating from ecartis to Mailman might be a real pain...
So the cosmetic solution you suggesting might be the only one.
 
> What do you mean with "the most work"? :)

Development.

> Content creation? Yes.
> But I am not a Zope or Python programmer. I could learn it, but I'd have
> to invest a lot of time to get something done. That's not good.
> Small changes like some of the ones we plan for Trac are not a problem
> for me. I'm willing to read Plone+Zope tutorials and learn how to use,
> customize, and maintain it (if we want Plone or whatever). IMHO, we need
> at least two people who can maintain Plone, so we don't rely on only one
> person.

Well, that applies to any system we go with. Tic has no Zope experience and 
tends to go with the latest Python fashions (I hope he'll forgive me for 
that) but I'm sure he'd be able to help me with some of the low level stuff. 
Plus we really should have as few systems as possible. Regarding content 
administration and creation: I am convinced that TALES makes this relatively 
easy and, more importantly, safe.

tic, do you want to take a look at Zope 3 and see how it compares with Django 
for development?
 
> RailFrog 0.5 was released today. It's not targeted at production use.
> Just a first step. Let's wait a little bit longer and see if their
> query-based idea can be made usable enough...otherwise, go with Plone.

mm, Michael prioritises the CMS which would mean getting something up and 
running fairly soon.

Watch this space.

Charlie
-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List

Other related posts: