Karim Yaici wrote:
> Hi guys,
> I found this article written by someone from Quixote concerning Zope,
> describing its weaknesses and possible future development
> http://www.amk.ca/python/writing/why-not-zope.html

This guy is quite far up his own arse :-)

It's probably more useful to work around the problems he describes
rather than bitching about them and telling people not to use Zope:

The 'no grep' is probably the most serious of his points. You can easily
get around it though, by using a ZCatalog. Admittedly, a decent search
and replace interface (which I'm plugging for on zope-dev ;-) would be
really nice (Zope 3? ;-)

No CVS is also a problem, but with the improvements in the History tab
and the like, this less of an issue. Besides, it's again easy to work
around by keeping CVS-ish stuff on the filesystem either by putting them
in python products or HTMLFiles. There's even ZCVSMixing should you
really be pedantic.

The test suite stuff is true for any web application, as has been
discussed on the XP lists (so I'm told ;-) That said, there's ZUnit and
PyUnit now, so I'm not sure that his opinion on this is valid at all.

His comments about DTML are all valid, but it's a choice he'd made to
write logic in DTML and he's a fool for doing so. IMNSHO, all 'logic'
should be kept in python and you should never need to use the "" in a
DTML tag. If you do, you're doing too much in DTML. Put it in a product
or one of Evan's new-fangled python methods (although these aren't
CVS'able, so I'd advise against it, unless is 'python scripting') If
used this way, DTML actually provides quite a nice scripting layer for
people who only understand/care about HTML, and there's the promise of
XHTML for the future.

He sees DTML's 'dynamic scoping' as a hinderance, it's actually one of
its strengths. Yes, it can be confusing, but maybe you should just write
code which doesn't make assumptions about variables, or handles the
cases when they're not there. The same is true of acquisition and the
namespaces concepts, maybe with better documentation, people like him
wouldn't have such problems.

Zope's built in FTP server is one of it's huge stengths, IMO. He hasn't
realised this and so bitches about it. You can always turn it off you
know! Likewise the HTTP server, run Zope as a CGI if you must! :P

Oh yeah, TTW editing does _not_ mean code has to live in the ODB as I've
already mentioned.

Of course, in being behind Quixote, this guy has an alternative motive
for slagging off Zope, but I do wish he wouldn't. In (almost) his own
words, he just wants a filesystem of python scripts to build his
website. Fine, but that doesn't solve a lot of people's problems and has
a lot of limitations, hence Zope came into being. Yes, it's a complex
beast but, if handled correctly, it'll save you loads of development
time and leaves you with a graceful, quick application that is
seperately configurable and scriptable, and has a _lot_ of code re-use.
I'm pretty sure this is true for the vast majority of web applications
but, of course, there are exceptions, although I'm not sure MEMS
Exchange is one of them ;-)

The one problem with Zope that he _should_ have mentioned is this: You
have to try pretty hard to write nasty code in Python, which si why it's
so great. Conversely, it's quite easy to build 'nasty' applications in
Zope that are messy and hard to maintain. Such is life, that's a
possibility I'm willing to live with for the power that Zope gives me.



Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-dev )

Reply via email to