Zope vs PHP for the Linux guru
Mark
I've been doing web app development for the last 3 years using php. I
already plan on learning Python to use as a rapid GUI development
language(maybe even replace some of my perl-use) and was curious about Zope.
I currently develop applications using php to query both remote and local
databases. I use local MySQL databases for fast read-only queries, and use a
remote MS SQL 2000 database for storing mutable data.
I use mod_php compiled into Apache 1.3.xx, and run php apps that range from
a few hundred lines to over 50k. DB access is through php's API using
MySQL's native libs and FreeTDS for connecting to SQL.
On the larger php apps I use an OO design model to keep the project
managable. My smaller apps are pretty much just quickly thrown together
scripts.
Right now I run it all on one Linux box, but have plans on creating farms
of apache servers for future scalability.
Some questions I had about Zope where:
Is developing apps in it a quick process? Php is a very rapid language to
develop in and that has become my most favored trait of the language.
Does Zope have good database support? Is it faster, slower than php with
database queries?
I'm assuming Zope will be better than php for large project development?
Is Zope easy for newbies to learn? I'm not a newbie, but we do have
some clients learning to program on our seperate Cold Fusion server, they
find it easier than php. I'd love to get them off Cold Fusion and onto a
more cost effective open source solution.
Does Zope scale well in large deployments? Any kind of support for web
server farming?
Any other major differences from php? Good things about it, bad things about
it?
Thanks for any input.
-Mark
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----
Cameron Laird
.
.
Good questions.
Very good questions, in fact. It's going to be tough
to answer at the same high level.
Zope development is breathtakingly swift--in the hands
of an expert. As wonderful as Zope is, though, it's
hard to make a case that it's easy to learn. It's pro-
bably the case that it lacks just the right bit of
documentation, or examples, or something; in any case,
newcomers consistently report rather extended intervals
before they "get" the Zope way of working.
In principle, you can do lots of neat stuff with Zope
"out of the box". In practice, there's enough of some-
thing missing from the documentation that few beginners
realize at the beginning what they can do with Zope.
PHP database support is unmatched. Zope supports lots
of DBs, but they're not all built-in, as with PHP. On
the other hand, you seem actively involved only with
MySQL and SQL Server, so maybe you don't need much da-
tabase support.
Overall, people who try both Python and PHP generally
come back to the former. CF just doesn't have many
attractions, once someone's enjoying Python. HOWEVER,
people like your target audience seem rather consistently
to "catch on" to CF and PHP quicker than they do with
Zope.
Zope scales fine. There's a lot that goes into this;
the one-line summary is that Zope more than holds its
own.
It does NOT support "Web server farming" of the sort
I suspect you have in mind, though. There's no parti-
cular reason it doesn't (and maybe someone's fixed
this recently); it's just that no one's gone to the
trouble of making it a reality.
Overall, Python's just a better language than PHP,
and Zope addresses an incredible range of Web service
question. For doing the first two or three Web-bish
things that most developers need, though, PHP has a
track record of being easier to get right.
--
Cameron Laird <cla...@NeoSoft.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Richard Jones
> Zope development is breathtakingly swift--in the hands
> of an expert. As wonderful as Zope is, though, it's
> hard to make a case that it's easy to learn. It's pro-
> bably the case that it lacks just the right bit of
> documentation, or examples, or something; in any case,
> newcomers consistently report rather extended intervals
> before they "get" the Zope way of working.
The new Zope Book (freely downloadable) is a really good effort to remedy
this.
> In principle, you can do lots of neat stuff with Zope
> "out of the box". In practice, there's enough of some-
> thing missing from the documentation that few beginners
> realize at the beginning what they can do with Zope.
>
> PHP database support is unmatched. Zope supports lots
> of DBs, but they're not all built-in, as with PHP. On
> the other hand, you seem actively involved only with
> MySQL and SQL Server, so maybe you don't need much da-
> tabase support.
Zope supports a whole lot of stuff that doesn't ship with it - something I
hope to remedy. And it's a bit of a pain for a point-n-click user to get
started with - another thing I hope to remedy :)
See http://dev.zope.org/Wikis/DevSite/Proposals/BatteriesIncludedDistribution
> It does NOT support "Web server farming" of the sort
> I suspect you have in mind, though. There's no parti-
> cular reason it doesn't (and maybe someone's fixed
> this recently); it's just that no one's gone to the
> trouble of making it a reality.
I'm not sure of the specifics, but doesn't ZEO handle this?
Richard
Paul Winkler
<ric...@bizarsoftware.com.au> wrote:
>On Friday 05 October 2001 08:24, Cameron Laird wrote:
>> Zope development is breathtakingly swift--in the hands
>> of an expert. As wonderful as Zope is, though, it's
>> hard to make a case that it's easy to learn. It's pro-
>> bably the case that it lacks just the right bit of
>> documentation, or examples, or something; in any case,
>> newcomers consistently report rather extended intervals
>> before they "get" the Zope way of working.
>
>The new Zope Book (freely downloadable) is a really good effort to remedy
>this.
... although (probably due to timing) it doesn't cover Page Templates
which are very, very cool - probably much better in the long run than
Zope's other (older) template language, DTML, and with important
advantages over just about every other dynamic web system out there.
There's a good introduction to ZPT linked from the front page of
zope.org this week: http://www.zope.org/Documentation/Articles/ZPT3
IMHO, a lot of the difficulty of grokking Zope is understanding what
the different parts of Zope are and how they relate to each other.
1) the through-the-web management interface, the ZMI.
2) the filesystem-like view that ZMI provides of objects in the Zope
database, the ZODB.
3) calling object methods by URL
4) page templating languages, DTML and ZPT. In practice, you'll need
to know a little python here too.
5) Acquisition, the process by which objects in the ZODB can
search in their parent Folders for other objects.
6) the security system
7) extensions written in python, which live on the
filesystem, either as small External Methods or as possibly quite
large Products.
8) extensions written as ZClasses
9) the ZCatalog
... for starters. :)
All of these things play their part in zope, and you will need at the
very least a working understanding of 1 - 6; anything non-trivial will
require Products or ZClasses too. And any site that needs searching
will need ZCatalog.
>> It does NOT support "Web server farming" of the sort
>> I suspect you have in mind, though. There's no parti-
>> cular reason it doesn't (and maybe someone's fixed
>> this recently); it's just that no one's gone to the
>> trouble of making it a reality.
>
>I'm not sure of the specifics, but doesn't ZEO handle this?
This might make interesting reading:
http://www.zope.org/About
--Paul Winkler
Benjamin geer
> Zope scales fine. There's a lot that goes into this;
> the one-line summary is that Zope more than holds its
> own.
Has the Python interpreter's global thread lock caused any
difficulties in getting Zope to scale well? If so, I'd be very
curious to know how this hurdle has been overcome.
I often use Python as a cleaner alternative to shell script, but the
idea of a global thread lock after every fifth instruction has always
made me wary of using it for anything in which performance is
critical.
Could anyone fill me in on the current status of the
global-thread-lock issue? Is there a consensus on whether it's
important, and if so, what should be done about it?
Benjamin
Duncan Booth
news:4bf6cf6d.01101...@posting.google.com:
>> Zope scales fine. There's a lot that goes into this;
>> the one-line summary is that Zope more than holds its own.
>
> Has the Python interpreter's global thread lock caused any
> difficulties in getting Zope to scale well? If so, I'd be very
> curious to know how this hurdle has been overcome.
I believe that Zope 'solves' the global thread lock problem by expecting
you to run multiple processes. So long as you run as many processes as you
have processors
In general Zope handles scaling by means of ZEO. This splits off the object
store into a separate backend process with one or more front end Zope
servers running as ZEO clients. If you are running on a multi-processor
machine then you could run multiple instances of Zope talking to a ZEO
server on the same or a different machine.
A ZEO server can also be a ZEO client, so for a really big system you can
build a tree of ZEO servers.
--
Duncan Booth dun...@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
Nomad
<dun...@NOSPAMrcp.co.uk> wrote:
>In general Zope handles scaling by means of ZEO. This splits off the object
>store into a separate backend process with one or more front end Zope
>servers running as ZEO clients. If you are running on a multi-processor
>machine then you could run multiple instances of Zope talking to a ZEO
>server on the same or a different machine.
>
>A ZEO server can also be a ZEO client, so for a really big system you can
>build a tree of ZEO servers.
Now, that could be damn cool.
--
Nomad
Wondering of the vast emptyness of the 'net
in search of something cool.