[EuroPython] EPC 2005: where and when?

[Julien Anguenot]

Hello,

> 
> I first investigated Zope when it was still called bobo. I haven't
> used it very much though, but I've used ZODB in a fairly sized system,
> and I've certainly played around with both Zope and Plone now and then. 
> I even own two paper books on Zope, and read parts of them. Zope and
> Plone never seemed right for any of sites I built, but I'm hoping that 
> Zope 3 will turn out to fit my needs better. It seems to be going in
> the right direction, but this has little to do with EPC. So, obviously
> it's possible to have complints without being totally Zope ignorant.
> 

Zope3 is an app server not a CMS. (ie : framework to built sthg)

> 
> It's clearly possible to make Plone sites feel more polished than the
> out-of-the-box look of the current EPC site, and perhaps a round peg
> will actually fit in a square hole eventually...
> 

Try CPSSkins on top of Plone and wear your glasses ;) You will be amaze 
about what you can do with your mouse to change the look & feel and 
manage portal portlets;

> I don't want to ourage anyone from working with it, and I'm really
> greatful for all the efforts made to make EPC happen, both in 2004, in
> previous years, and in the years to come. But I still think it's a poor
> fit to use a CMS tool for business transactions and scheduling. On the
> other side, it's impossible (or at least uneconomical) to build perfect
> systems.
> 

If you need more powerful collaborative tools such as workflows, 
versionning, workspaces etc... you really should take a look at CPS.

> 
>>I have also com tu udnerstand 
>>that using Zope-based software is, to my utter amazement, a politically 
>>controversial issue in the non-zope python world.
> 

Well, in France the Zope market is fairly good et least.

> 
> Zope software is controversial to many Python programmers, because it's
> conceptually very different from Python. For instance, if you (like many 
> Pythonistas) use the standard Unix tools to improve your productivity, 
> and apply the many-small-tools-doing-one-thing-well Unix philosophy, 
> Zope will fit poorly in your world. I don't see this as "political".
> 

don't get why ?

> It's not just that it's a Framework, imposing control over your code, 
> it also places your application instructions in an object database, 
> together with the application data, which is something most programmers
> try to avoid for good reasons. It also makes you work a lot in HTML 
> forms, instead of your favourite editor.

that's definitely wrong. (Products are made for that)

> 
> I don't find it surprising at all that there is controversy around Zope,
> concerning that it's been described as the Python killer application,
> while being conceptually so different from Python as a development tool.
> "Normal" Python development is very well integrated with traditional
> software development tools and environments.

I'm working with Xterm and emacs with Zope without any problem. Never 
using the ZMI except for refreshing the Products.

> 
> For me it's in many ways similar with software development in VBA in
> applications like MS Excel or Access. Just as in these tools, you
> get a lot of features for free, there are ways of "breaking the bonds"
> both when it concerns the location of code, filesystem integration and
> with editing tools etc, but it's still a bit awkward. Just like Excel
> and Access, it can be very useful, and also very frustrating.
> 

I can't believe you comparing M$ stuffs and Zope ...

> It seems to me that the Zope developers are working hard to eliminate
> the problems and make it more Pythonic, and many of the best Python
> programmers are involved in this, so I'm very optimistic about its 
> future.
> 
> 

me too  :)

	J.

-- 
Julien Anguenot | Nuxeo (Paris, France)
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66