Re: Open Source CRM - Options? - Mailing list pgsql-general
From | Will LaShell |
---|---|
Subject | Re: Open Source CRM - Options? |
Date | |
Msg-id | 1211940620.5988.71.camel@localhost.localdomain Whole thread Raw |
In response to | Re: Open Source CRM - Options? ("Andrej Ricnik-Bay" <andrej.groups@gmail.com>) |
Responses |
Re: Open Source CRM - Options?
|
List | pgsql-general |
On Wed, 2008-05-28 at 10:46 +1200, Andrej Ricnik-Bay wrote: > On 28/05/2008, Kevin Hunter <hunteke@earlham.edu> wrote: > > > And its python :) > > That's actually a bigger plus than folks may realize because all three > > communities (Django, Postgres, Python) share the > > "do-it-the-right-way,-not-just-the-quickest/easiest-way" mentality. (At > > least in my experience.) From an overall quality perspective, this is a > > huge win for all involved. And if you're developing, you will > > appreciate the chat rooms/mailing lists/community-in-general for all > > three for just this reason. > > How does Zope/Plone fit in there as an alternative in your opinion? :) > I will offer my experience on this one. We were attempting to use Zope/Plone for the GNOME.Asia summit website. In short, it was a disaster for us. Starting with no experience in Plone the learning curve was very very high. I was able to make some initial theme changes, but when we started to add custom objects, new "page types" to display things like speaker profiles, abstracts, and adding new data to registered user objects the framework itself really got in the way. We spent some time with the Plone community but there were no clear answers on what the errors we were seeing actually meant, several times the answer was "Well, you have something wrong, but it looks like it should be working....". Setting up the development environment on each persons system was non trivial as well because the "preferred" method of using Plone/Zope is with a "buildout", which is basically a magical script which can download and set up everything. It sounds easy enough, but in practice it can turn ugly. They offer pre-established Plone/Zope tarballs, but when we used them and we had some issues trying to use some of the extra modules, the first answer was always "are you using a buildout, because then it would be easy for you". Judging by the questions that were being asked on the Plone mailing lists / IRC channel there are some things that need to be changed in the default Plone configuration. I saw "Why doesn't my Plone start" as many times as I have seen "Why is select count(*) from my_super_blog_awesomesauce; so SLOW!!!!!" on the Postgresql mailing list. The different being there were 10 different "common" answers for the not start question. Using version control on the customization "product" you create can be hard too, because even though you commit your code, and the other developers check it out, some of the changes your product make to Plone's layout and display cannot be reverted without essentially deleting and starting the database from scratch again. Not optimal. Oh, and to top it all off, it really wants to use ZODB for its datastore. Using an external data back-end is supported, but things can break unexpectedly. I will say that Zope/Plone has had a lot of time spent on it and the developers that know it very well can do some very interesting things with it pretty quickly. Django, much much easier learning curve. It just doesn't get in your way. Nice support for sqlite, postgresql, mysql. Django's ORM is very easy to understand. The template system syntax is very straightforward with excellent separation from the backend code. The web designer on the team knows no python at all and has been able to work on the templates with no problems. Time spent with Zope/Plone: 4 weeks Result: base plone installation has a new theme. website 15% complete. Eta completion: Infinity Time spent now with Django: 1 week 2 days. Result: Website 90% complete. Eta completion: 3 days. I have no desire for this to escalate into a Django vs Zope/Plone debate, so please no one turn it into one! I am sure that if we had known more Zope/Plone or had more time to learn and figure out how to do things in the "Plone way" we could have had more success with it. Sincerely, Will LaShell > > > Kevin > Cheers, > Andrej
pgsql-general by date: