Jens Benecke wrote:
On Mon, Apr 02, 2001 at 08:00:41PM -0700, Michael R. Bernstein wrote:
Steven Grimes wrote:
... With Zope, I can build (for example) a fairly sophisticated Intranet for a company in a couple of days, without breaking into a sweat. This Intranet will include personal folders for the users, a bug/ticket tracker, industry news, departmental pages, and any of a dozen other goodies like discussion forums and a collaborative documentation system.
Just a small question in between: You can build this site because all the required functions are available as Zope modules (or "products") and you just need to plug them together, right? How would Zope cope if you did _not_ have these ready-made modules or if they didn't fit your needs?
Mmm. I can build this site that *quickly* because ceratin functionality is available as Products, or part of the Zope core functionality. Authentication, security, and delegation are built in, for example.
What I mean is this: In PHP you _can_ add PHPLIB, which is a class library does user management, authentication, sessions, forms with automatic error checking (both Javascript and server-side), database-independant SQL connections and much more for you. Soon there will be PEAR, which is comparable to CPAN for Perl and will offer all kinds of modules.
But if you need to do your _own_ applets (e.g. plug in something like a client-side Javascript calendar that connects to a server-side SQL-DB before displaying itself and when acted upon pre-fills some input fields - just an example), how difficult would that be?
Client side javascript (Bleh!). :-) I've built several small applications from scratch, such as an FAQ manager, and I'm working on a couple of bigger ones now which I'll release as Zope Products.
I know the OOP model fairly well, so I understand you can extend Zope's classes to an extent to fit your needs. However ATM I'm a little worried about Zope when I see people posting 20-line DTML code just to squeeze a string through a regexp. (Or five-line Python - Perl, PHP, etc. can do it in one.)
Python emphasizes legibility over terseness. It's a trade off that won't appeal to some, I'm sure. I wouldn't suggest using DTML for your applications business logic, anyway. Use Python for that. DTML is very well suited to presentation logic tasks. This also helps enforce separation of content/presentation/logic. Again, a trade off that may not appeal to some.
Then I can refine it over another couple of days. By any sane measure, this is far more cost effective for a company than paying two or more programmers to build something equivalent in a couple of months, just to save a grand on hardware.
That's precisely why I started looking at Zope. I'm not interested in a Web GUI, in dividing content and design (We're a team of two developers, we can organize ourselves without CVS like functions) or such. What I'm interested in is making my site
- easy to extend later (with well sorted out OOP, this should be manageable)
True.
- easy to manage even if it gets bigger (not having to worry about things like "where do I put this new feature")
Zope's pretty good at that, IMO.
- and secure, of course. (ie. built-in filtering for FORM variables and such things would be nice. PHP does this with addslashes() and the like).
Well, Zope does automatic casting of variables by using a simple naming convention in your forms (ie. <input name="size:int">) the ':int' is stripped off the actual variable name when you want to access the value.
Last but not least: Is there a Zope intro for people like me who already _have_ a couple years of Web development with PHP and other languages and don't need things like "insert common HTML header/footer" presented as Zope's primary features?
Have you checked out the New Riders Zope Book: http://www.zope.org/Members/michel/ZB Or this one: http://www.handshake.de/~dieter/pyprojects/zope/book/chap1.html http://www.handshake.de/~dieter/pyprojects/zope/book/chap2.html http://www.handshake.de/~dieter/pyprojects/zope/book/chap3.html HTH, Michael Bernstein.