RE: Any comments from ex-PHP developers?
At 11:21 17/12/2002 -0500, "Wankyu Choi" <wankyu@neoqst.com> wrote:
I don't consider myself an *ex*-PHP developer, but just wanted to share my thoughts.
Thx a bunch Wankyu for sharing you thoughts on PHP vs. Zope. As a matter of fact, I'm playing with PHP + FastTemplate + MySQL, and it looks interesting. I still need more about what Zope would offer in addition to this. To sum up what you wrote: Pro's - Zope makes it easier to separate logic and presentation : honestly, I don't see the difference between PHP scripts outsourcing display to templates and Zope + DTML/ZPT - Python is truly OOP : What is missing in PHP4? Multiple inheritance? Con's - there are a lot more PHP developers than Zope developers, hence more docs and more help in case of need - Zope uses its own DB instead of a filesystem. But then, nobody complains when data are saved in other DBMS's, so why do they complain about ZODB? - ZPT is a bit slow, but maybe as slow as PHP and some templating engines Thx again Fred.
From: "Frederic Faure" <ffaure@bigfoot.com>
- Python is truly OOP : What is missing in PHP4? Multiple inheritance?
Well, yes, but mostly an object store.
- Zope uses its own DB instead of a filesystem. But then, nobody complains when data are saved in other DBMS's, so why do they complain about ZODB?
This is actually a pro, not a con. :-) The fact that that DB is also file based, and doesn't require you to set up an SQL-database is another pro.
Hi All, In article <002e01c2a605$b94af5a0$3fcc96c1@Xochiquetzal>, Lennart Regebro wrote:
- Zope uses its own DB instead of a filesystem. But then, nobody complains when data are saved in other DBMS's, so why do they complain about ZODB?
This is actually a pro, not a con. :-) The fact that that DB is also file based, and doesn't require you to set up an SQL-database is another pro.
Eek! This makes it sound as though the use of the ZODB and an external RDBMS are mutually exclusive - *NOT SO*!!! in non-niche situations, if you need an RDBMS, you need an RDBMS - it's a case of using the right tool for the job. - The fact that the ZODB dB is integrated into the application server and doesn't require you to set up an SQL-database for data management tasks which do not call for one is a "pro". - The fact tha Zope will "play nice" with an external RDBMS for data management tasks which do call for one is /another/ "pro". Regards, PhilK Wed, 18 Dec 2002 08:26 GMT @ Ganesh Email: phil@xfr.co.uk / Phone, Voicemail & Facsimile: 07092 070518 Tell me and I forget. Show me and I remember. Involve me and I understand. - Chinese saying
I read a post by somebody earlier saying something about "using the right tool for the job." Bravo, well said! And, I have not heard this "Pro" for PHP yet, so I'll say it now: As an entrepreneur developing products for market, I am ultimately concerned about how the market will accept accept my product. In my line of work (developing Internet software products), I want to choose (and develop) a product which will have the highest possible acceptance in my market segment. Truth be told, PHP is still WAY ahead of Zope in terms of support and deployment on Unix by Unix network administrators. In my market niche, the support ratio for PHP:Zope is something like 50:1. No hard feelings, but as an entrepreneur, I cannot afford to ignore this single fact. However, as an entrepreneur, I also cannot ignore the fact that Zope is rising quickly in popularity. Within just the last 9 to 12 months, I've seen Zope become a common topic of conversation, have seen seasoned network admins begin to consider it, and have even seen some begin to trust it. That's big (!) for such a short period of time! So, I'm on the wagon for Zope. But right now, the fact is PHP still has better support and market penetration. Bryan
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Philip Kilner Sent: Wednesday, December 18, 2002 12:37 AM To: Lennart Regebro; zope@zope.org; Frederic Faure Subject: Re: [Zope] Any comments from ex-PHP developers?
Hi All,
In article <002e01c2a605$b94af5a0$3fcc96c1@Xochiquetzal>, Lennart Regebro wrote:
- Zope uses its own DB instead of a filesystem. But then, nobody complains when data are saved in other DBMS's, so why do they complain about ZODB?
This is actually a pro, not a con. :-) The fact that that DB is also file based, and doesn't require you to set up an SQL-database is another pro.
Eek!
This makes it sound as though the use of the ZODB and an external RDBMS are mutually exclusive - *NOT SO*!!! in non-niche situations, if you need an RDBMS, you need an RDBMS - it's a case of using the right tool for the job.
- The fact that the ZODB dB is integrated into the application server and doesn't require you to set up an SQL-database for data management tasks which do not call for one is a "pro".
- The fact tha Zope will "play nice" with an external RDBMS for data management tasks which do call for one is /another/ "pro".
Regards,
PhilK
Wed, 18 Dec 2002 08:26 GMT @ Ganesh
Email: phil@xfr.co.uk / Phone, Voicemail & Facsimile: 07092 070518
Tell me and I forget. Show me and I remember. Involve me and I understand. - Chinese saying
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Hi Bryan, In article <BEEHJMMMOGNIPHGPIKENAEFBCFAA.Bryan@capitanoweb.com>, Bryan Capitano wrote:
PHP is still WAY ahead of Zope in terms of support and deployment on Unix by Unix network administrators. In my market niche, the support ratio for PHP:Zope is something like 50:1. No hard feelings, but as an entrepreneur, I cannot afford to ignore this single fact.
Interesting take. Of course, if you are providing a hosted solution (e.g. providing a service as well as / instead of selling a product), then this problem goes away... I was once involved in an e-Commerce product based on a proprietary (and, as it turned out, extremely flaky) script engine. Of course, we had automatically priced ourselves out of the market for any work except that calling for a dedicated server, because hosting operations were v. wary of the engine. Value of script engine over and above Perl / Python / PHP = 0% Contribution of script engine to demise of product and company = 100% Lesson learned = If you must pick your own tools, provide an end-to-end solution and reap the benefit of your choice yourself... YMMV! Regards, PhilK Wed, 18 Dec 2002 19:50 GMT @ Ganesh Email: phil@xfr.co.uk / Phone, Voicemail & Facsimile: 07092 070518 Tell me and I forget. Show me and I remember. Involve me and I understand. - Chinese saying
Thx a bunch Wankyu for sharing you thoughts on PHP vs. Zope. As a matter of fact, I'm playing with PHP + FastTemplate + MySQL, and it looks interesting. I still need more about what Zope would offer in addition to this.
Okay, just trust me on this one: a lot, just WHOLE LOT more. That much I can say. Don't judge anything until you REALLY get your hands dirty with Zope. A bit of my experince will speak volume. I started this set of projects (re-doing millions of PHP code; three-to-four years 24/7 worth of work) a year ago. First, of course, in PHP. Tried PHPNuke/PostNuke...didn't like them that much. Started building my own: NeoPortal. One day, just stumbled upon this Zope thing they were talking about. It was not love at first sight. I really didn't like Zope that much the first time I met it. BUT loved how Python worked. Yes, I took up Python. Didn't know beans about the language before then. Bought a book titled 'Web Programming in Python': a great well-written book on web developing/template engines, etc. It even got its own Portal project (named Slither). Guess what? I immediately took to the idea and started extending it. A month or so passed by. Again, I came to see Zope in an article. Okay, I thought, I might learn a thing or two from it.... Spent a week or so playing with Zope. I didn't get back to Slither. I came to live with Zope. Why reinvent the wheel? You need to get your hands dirty first. Zope doesn't look enticing at first sight. You have to look INTO it and get soaked in it to really feel what it's like working in Zope.
Pro's - Zope makes it easier to separate logic and presentation : honestly, I
don't see the difference between PHP scripts outsourcing display to templates and Zope + DTML/ZPT
Again... BIG difference I should say. You don't get the hang of what Zope and its power tools like DTML/ZPT can do for you unless you really get to them. Zope is an application server. Not just a template engine. For example, you'd have to spend months to get the likes of Zope's acquisition/security machinery. That alone, I don't want to use any other tool when developing web application. Take NeoBoard again for example. That threaded look, I pulled my hair to implement it in PHP. In Zope, I didn't even try. Acquision machinery/ZPublisher did all the work.
- Python is truly OOP : What is missing in PHP4? Multiple inheritance?
Half of what any good OOP introduction book would say... is missing from PHP4. But, if you don't feel what's missing, that means you don't need them anyway;-) And Zope objects are persistent. You don't get that from PHP. Just imagine you create an object and that object comes with its own persistent database. What a boon. I don't even use session variables anymore.
Con's - there are a lot more PHP developers than Zope developers, hence more docs and more help in case of need
Yes. It's like when I switched over to PHP from Perl back in 1997 to 1998, when no more than a couple of books were on the market (with dubious quality at that.) With Zope... well.. doc strings in Zope code are my best resources now;-&
Zope uses its own DB instead of a filesystem. But then, nobody complains when data are saved in other DBMS's, so why do they complain about ZODB? - ZPT is a bit slow, but maybe as slow as PHP and some templating engines
Like I already mentioned, ZODB, in itself, is a good thing. But it's not a database you normally see. Not an RDBMS like MySQL. You don't put your files and images into MySQL tables, for example. ZODB is supposed to take them all. The whole site goes into ZODB: db + filesystem, sort of. There are a couple of ways out like LocalFS and its likes, but basically that's what you do with ZODB. The stock ZODB that comes with ZOPE puts everything in one single file (called file storage). It gets bigger and bigger as you add data. You can't incrementally back it up. Zope supports versions. You create a counter and it bloats it up since ZODB stores all of your counter object's previous versions until you pack it away. That portal project I mentioned above... I have too many users now with their data in MySQL, on the filesystem... all that data adds up to dozens of giga bytes. I don't think I want to put all that data (and their duplicate versions) into this ZODB file storage until I get a more flexible storage like directory storage. Again, what counts is your priorities. If you don't need what Zope offers, you might want to stay with AMP. Finally, as any good language or platform, you get what you give with Zope. (But once you get there, you don't wanna get back;-) Best Regards, Wankyu Choi --------------------------------------------------------------- To the dedicated staff at NeoQuest, language is not a problem to be dealt with, but an art waiting to be performed. --------------------------------------------------------------- Wankyou Choi CEO/President NeoQuest Communications, Inc. 3rd Floor, HMC Bldg., 730-14, Yoksam-dong, Kangnam-gu Seoul, Korea Tel: 82-2 - 501 - 7124 Fax: 82-2-501-7058 Corporate Home: http://www.neoqst.com Personal Home: http://www.zoper.net, http://www.neoboard.net e-mail: wankyu@neoqst.com ---------------------------------------------------------------
participants (5)
-
Bryan Capitano -
Frederic Faure -
Lennart Regebro -
Philip Kilner -
Wankyu Choi