I have only minor experience with PHP so this may be ignorant, but isn't programming a web application with PHP scripts more comparable to programming such an application with Python scripts? If PHP scripts are handling HTTP requests directly, that can also be done with pure Python scripts. But if I have to put together a comprehensive web application I'm going to be developing a lot of scripts, unless I use an integretaed, pre-made package of scripts. But then, that is really what Zope is, isn't it? Call me confused, Bill At 10:17 AM 4/23/02 -0700, you wrote:

I am not a PHP guy by any means, but I imagine having to run an extra server (Apache, Postgres vs Apache, Zope, Postgres) means there is another server process to watch, manage, start/restart. You don't have to do those things with PHP scripts.

Perhaps someone with experience with a larger PHP implementation under their belt could let us know.

On Tuesday 23 April 2002 9:46 am, you wrote:

...

...

Plus the over head of running Zope instances is greater than PHP scripts.

Is this really ture for anything non-trivial?

---------- "The commandments of the LORD are right, bringing joy to the heart. The commands of the LORD are clear, giving insight to life . . . For this is the love of God, that we keep His commandments. And His commandments are not burdensome." (Psalm 19:8, 1John 5:3) <http://torahteacher.com/>torahteacher.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.346 / Virus Database: 194 - Release Date: 4/10/02

At 11:01 AM 4/23/02 -0700, you wrote:

But there are a lot of prepackaged scripts for Calendars, and database connections, shopping carts, etc... for PHP. So there's got to be more that just the prepackagedness of Zope to chose it over PHP.

Yes, that is important. Of course, there are a lot of Products (pre-packaged scripts) available for Zope that do these soft of things. Have you checked the Downloads page (http://www.zope.org/Products)? It is interesting that right now there is a sort-of "batteries included" topic going on in this list debating the merits of what goes into the core of a Zope release. But whatever ends up in the core, there are many, many good add-ons already out there. Bill ---------- "The commandments of the LORD are right, bringing joy to the heart. The commands of the LORD are clear, giving insight to life . . . For this is the love of God, that we keep His commandments. And His commandments are not burdensome." (Psalm 19:8, 1John 5:3) <http://torahteacher.com/>torahteacher.com --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.346 / Virus Database: 194 - Release Date: 4/10/02

From: "Jason Spisak" <jspisak@lycoris.com>

I think Oliver's point about transaction safety is a big win. I might convince them just on that. But I'm still looking for more ammunition.

Basic things from the top of my head: - Full OO = short development time = cheaper development. - Integrated security = less chances of unsecure scripts. - Transactational security. - Undoable transactions. - Integrated user management. - Transparent scalability. - Integrated rights/permission management. ( No, it's true that they probably do not need better permission management than they can build with PHP. But with Zope you don't have to build it at all. It's alredy there.) These are the things you get for free with Zope that you don't get with PHP. I have also probably missed out on several.

In the same way that Java was a reaction to the wicked corruption of C++, PHP is merely a reaction to the wicked corruption of Perl. Any language whose design is based on imitating another crippled language is at a disadvantage to a language like Python that was well designed in the first place. PHP may seem like a good idea to someone who's only ever programmed in Perl and is sick of suffering, but compared to Python it's a toy. The same goes for Java: it only seems like a good idea when compared to C++, without considering language like Python or Lisp. But neither Perl nor Java are serious about easily interfacing to other languages and libraries, as Python is. Java's biggest problem is that it's intended to be as a weapon in the war against Microsoft, more than a programming language. So it's purposefully designed not to get along with other languages. The slogan "100% Pure Java" smacks of intolerance and racism. PHP doesn't suffer from such a debilitating political agenda as Java does, but it's even more of a toy language, no good for programming in the large, and it doesn't even have much of an advantage over JavaScript. Dr. Dobb's Journal covered the Lightweight Language Workshop at MIT: http://ll1.mit.edu http://www.ddj.com/documents/s=2287/ddj0202a/0202a.htm PHP wasn't represented at the workshop, since it's not usually considered an interesting language by people who know more than one. The Perl people in attendance made fools of themselves and were not taken very seriously, because what they said demonstrated their amateur grasp of language design. (I've included an excerpt from the article demonstrating that below.) I understand the argument that all Turing complete programming languages are equivalent in what they can compute. But programming language design goes far beyond Turing completeness: Language design is user interface design, because programmers are language users. Languages like Perl and C++ that ignore the important tenants of user interface design are badly designed languages. It's unethical to evangelize badly design languages, even if it's simply out of ignorance, and especially if it's in the name of job security through code obscurity. The fact that sombody's invested years in learning C++ or Perl is no justification for spreading the disease, when there are better more appropriate solutions available for free. -Don ==== http://www.ddj.com/documents/ddj0202a/ Most of the talks were relatively uncontroversial. However, during the Simon Cozens and Dan Sugalski presentation on Perl 6, the clash of cultures quickly became apparent. Cozens and Sugalski gave an excellent summary of Perl 6's run-time engine, but their interaction with the audience was awkward, and the ensuing discussion, although reasoned, was heated. Several attendees noted during the talk that the Perl community seemed to be reinventing the wheel in areas such as virtual-machine implementations and garbage collection. At times, the feedback included some not-so-subtle barbs. To their credit, Cozens and Sugalski accepted this feedback gracefully, requesting URLs so that they could examine the appropriate papers themselves. Unfortunately, they occasionally inadvertently incited the crowd with their flippant remarks. Sugalski, for example, explained that Perl's run-time engine needed to support a number of high-level programming concepts, and he showed a slide that listed some of them. When coming across "continuations" on his slide, he said, "Let's skip that. I don't really understand them." Gasps were heard throughout the room, as Sugalski's blunt confession seemed to be proof that "Worse Is Better" communities were indeed ignorant of computer science. Sugalski also stated that, for academics, "Perl is not very interesting." Although several members of the audience nodded in agreement, it was an unfortunate claim to make, because it was clear that neither Sugalski nor Cozens really knew what academics were interested in. ====

"Don Hopkins" <xardox@mindspring.com> writes:

The fact that sombody's invested years in learning C++ or Perl is no justification for spreading the disease, when there are better more appropriate solutions available for free.

accepted. Nicola Larosa <nico@tekNico.net> writes:

This is great advocacy, but maybe a little too inflammatory, and "spreading the disease" is going a little too far. Anyway, I mostly agree on what you said, as most around here, I presume.

The problem is, these points are true from the general point of view, but are unhelpful, and probably dangerous, when you have to confront developers already attached to such broken languages.

Or decision makers, who decide development Platforms for a Project (which most often are *not* the developers). I am not free to choose my Platform. It's sad, but it's a fact. If I could, I would do most of my development in lisp (I love it). But its neigh impossible to get someone to support lisp. Especially when you are forced to interface with the (non)standards of some unnamed proprietary entity ;-/... So most of the Time, the choice of languge/development Platform is by what is supported by the necessary surrounding technologies. At least that's how it is here. Stefan.

On Wed, 24 Apr 2002, Joseph Cheek wrote:

nope. that's a function of the DB, not PHP. if the DB is written right it will roll back/commit transactions automatically. so this becomes an argument for zope over php+some really lame DB, not zope over php regardless.

8-)

[agreed that the linuxjournal commit/rollback code is hairy, but the folks there seem to like mysql for some strange reason].

The DB provides the transaction commit/rollback *capability*, but it is up to the application to *use* it. The DB can't commit or rollback automatically, because it doesn't know where the transaction boundaries are unless the application tells it. In PHP, that means *you* have to write the trasaction-start/-end/-rollback calls. Zope, on the other hand, wraps every web request in a transaction to the DB *automatically*, and does the rollback *automatically* if an error occurs in the web transaction. This is a very very cool feature of Zope, and saves a *lot* of programming effort. --RDM

Jason Spisak wrote:

[snip]

To recap what turned the tides were these wins:

1. Zope's security model is far more scalable and flexible than anything home brewed in PHP.

2. The scurity model is also audited by any, many people and tested and in production all over the place. ;-)

Security machinery present in Zope, to develop in PHP.

3. The ease of management for non-technical users to create and edit content was a big win since that interface is already created and ready to use in many cases.

Interface present in Zope, to develop in PHP.

4. The built in separation of db connectivity/transparancy is much better than taking the time to design that properly from scratch, or using connectivity tools that then needed to be 'connected' to the app in a safe and transparant way.

DBaccess layer is present in Zope, to design in PHP.

5. The transactional nature of Zope (although they didn't believe me when it came to rolling back multiple dbs) impressed them and if it really can mange a rollback from from a DB and transaction safety for inventory,etc...(which I know it can) then its a huge win.

Transactions support is in Zope, to develop in PHP. Thus I wanted to point out that PHP is not really what you can compare to Zope. PHP is comparable to Python. They are just languages. PHP community has excellent PHPnuke and PostNuke products which has unprecedented success. The is alsow Midgard, PHP CMS. Zope is Application Sever disposing a number of services to applications written with it. We should find competitor in PHP world to compare to. I do not know one. Speaking of Application Servers I can name ACS (TCL/Java) and Enhydra (Java). They are competitors of Zope, not PHP. Regards, Myroslav -- Myroslav Opyr zope.net.ua <http://zope.net.ua/> ° Ukrainian Zope Hosting e-mail: myroslav@zope.net.ua <mailto:myroslav@zope.net.ua> cell: +380 50.3174578

This means that every Update/Insert command make sthe ZODB grow, right? Has anyone had experience with Packing a site with high traffic in a case like this (RDBMS backend)? What happens? On Wednesday 24 April 2002 12:55 pm, Leonardo Rochael Almeida wrote:

On Tue, 2002-04-23 at 21:36, Jason Spisak wrote:

...

[...]

5. The transactional nature of Zope (although they didn't believe me when it came to rolling back multiple dbs) impressed them and if it really can mange a rollback from from a DB and transaction safety for inventory,etc...(which I know it can) then its a huge win.

Yes, of course it can, IF you use a properly trascationed DB and adapter. Psycopg fits the bill nicely, as do DCOracle2.

As for multiple DB rollback, yes, that works as advertised, and is actually really easy to believe if you explain them how it works. Truth is, Two-Phase-Commit was INVENTED (a long time ago, and not in Zope) to make it possible to commit or rollback multiple transactional entities at the same time. Zope is just an implementation of a TPC coordinator (I think, and I hope I got the vocabulary right).

In the course of a Zope transaction, any object that is invoked and wants to be notified of the tpc phases registers itself in the transaction machinery. Most of them inherit from Shared.DC.ZRDB.TM.TM. When a transaction is aborted or commited, the Transaction machinery notifies all registered objects. Each registered object then calls the respective actions in their backend drivers or whatever.

Cheers, Leo

-- Jason Spisak Marketing Director, Lycoris jspisak@lycoris.com, http://www.lycoris.com Desktop/LX: Familiar. Powerful. Open.

Thanks Leonardo, I was confusing the two. The encapsulation, yes that makes a lot more sense. On Wednesday 24 April 2002 2:44 pm, R. David Murray wrote:

On Wed, 24 Apr 2002, Jason Spisak wrote:

...

This means that every Update/Insert command make sthe ZODB grow, right? Has anyone had experience with Packing a site with high traffic in a case like this (RDBMS backend)? What happens?

No, and RDBMS update or insert does *not* cause the zodb to grow (unless zodb data is changed at the same time).

Perhaps you are confusing current-transaction-rollback and Undo? Zope supports the former with RDBs, but not the latter. That is, once the transaction is *comitted*, it can't be rolled back by Zope. Might be a nice feature to add, though, for databases that support it <grin>.

--RDM

-- Jason Spisak Marketing Director, Lycoris jspisak@lycoris.com, http://www.lycoris.com Desktop/LX: Familiar. Powerful. Open.

At 04:55 PM 4/24/02 -0300, Leonardo Rochael Almeida wrote:

As for multiple DB rollback, yes, that works as advertised, and is actually really easy to believe if you explain them how it works. Truth is, Two-Phase-Commit was INVENTED (a long time ago, and not in Zope) to make it possible to commit or rollback multiple transactional entities at the same time. Zope is just an implementation of a TPC coordinator (I think, and I hope I got the vocabulary right).

Note that this only guaranteed to work if all the database adapters involved in the transaction support two-phase-commit. Many do not, and thus may commit too early or too late in the course of a multi-database transaction. If you need multi-database commit, you'll need to verify that the adapter in question actually implements tpc_vote() as something other than 'pass'. :)

Excellent thinking. I'm guessing that the PyscopyDA handles that type of thing and makes sure that it doesn't get nasty. That's a big win for Zope when dealing with inventory and things like that. Thanks Oliver. On Tuesday 23 April 2002 10:33 am, you wrote:

Jason Spisak wrote:

...

You might remember me, I've been a big Zope fan since ZTables, and have recently been asked "Why Zope?". The project is commited to PostgreSQL and leaning toward PHP. Here's the project requirements for a softwre company:

Hardware Compatability List Software Compatability List Store/ECommerce User tracking and services like Pay for downloads Upgrades if they have a serial number paid up Billing/Invoicing for corporate accounts Inventory tracking CRM/Sales functions

They don't see that Zope's built in security machinery would beat something home brewed for what they expect to need it for. Plus the over head of running Zope instances is greater than PHP scripts.

What are the arguments for Zope in this context?

Transaction Safety?

When reading your requirements that was the first thing coming into my mind. I don't know how php does this, so I went to google and found http://www.phpbuilder.com/columns/linuxjournal200009.php3

Below is one snippet, notice all the ugly "//check for errors" and "//abort transaction". If someone knows where I misinterpret something or how php solves this, corrections welcome.

But wouldn't it be nice if we had an application server which would take care of all this for us?

Oh, wait ... ;-)

cheers, oliver

function cart_new() { //make the database connection handle available global $conn,$customer_id,$feedback;

//start a transaction query("BEGIN WORK");

//query postgres for the next value in our sequence $res=query("SELECT nextval('seq_customer_id')");

//check for errors if (!$res || pg_numrows($res)<1) { $feedback .= pg_errormessage($conn); $feedback .= ' Error - Database didn\'t return next value '; query("ROLLBACK"); return false; } else { //set that value in a local var $customer_id=pg_result($res,0,0);

//register the id with PHP4 session_register('customer_id');

//insert the new customer row $res=query("INSERT INTO customers (customer_id) VALUES ('$customer_id')");

//check for errors if (!$res || pg_cmdtuples($res)<1) { $feedback .= pg_errormessage($conn); $feedback .= ' Error - couldn\'t insert new customer row '; query("ROLLBACK"); return false; } else { //commit this transaction query("COMMIT"); return true; } } }

-- Jason Spisak Marketing Director, Lycoris jspisak@lycoris.com, http://www.lycoris.com Desktop/LX: Familiar. Powerful. Open. +1 425 869-2930 voice, +1 425 671-0504 fax

Oliver, Thanks, that's an important distinction. Not just one transaction item, but all the items you group into one 'business transaction' within the Zope application. Meaning (not that it's the case here) multiple different database writes, yes? Powerful stuff. I must have misinterpreted the presentation and business logic issue. While there will always be conditionals and certain small expressions in the presentation, it's the omission of the 'fetch, compute, allow' type stuff that makes the separation. I guess you can do this in PHP, since the display scripts can just call other pure PHP scripts and pass arguments. So that's not really as large a win. But with Zope, the ease is 'builtin' rather than 'programmed' in. Thanks again. On Tuesday 23 April 2002 11:34 am, you wrote:

Jason Spisak wrote:

...

Excellent thinking. I'm guessing that the PyscopyDA handles that type of thing and makes sure that it doesn't get nasty. That's a big win for Zope when dealing with inventory and things like that. Thanks Oliver.

Just to be clear about the extend of this transaction safety (just to be sure - you might know that), it covers everything done in one request, so that even several "independent" actions (be it relational database, ZODB etc.) are rolled back if something goes wrong. This means it not only doesn't get nasty, it becomes really nice ;-). You can seperate your SQL statements into different ZSQL methods and so on.

About the separation between content&layout, you are not obliged to use ZPT to get that (don't belive a certain Mr. Withers here ;)). You can also do that with dtml + python(-scripts). The point is that you can - in a natural way - design the application in zope that it's possible to change the layout later on without fear of breaking the functionality.

Yes, that's also possible with php (or perl), but this seems as natural as doing OO-programming in C to me.

cheers, oliver

-- Jason Spisak Marketing Director, Lycoris jspisak@lycoris.com, http://www.lycoris.com Desktop/LX: Familiar. Powerful. Open. +1 425 869-2930 voice, +1 425 671-0504 fax

About the separation between content&layout, you are not obliged to use ZPT to get that (don't belive a certain Mr. Withers here ;)).

Yes, you are.

You can also do that with dtml + python(-scripts).

No, you won't! Please, stop evangelizing broken languages! ...mmh, didn't I forget some smilies there? ;^))) -- Two witches watch two watches. Which witch watched which watch? Nicola Larosa - nico@tekNico.net

(apparently the latest versions of ASP also have the idea of using tag attributes to store markup code)

Naah, can't believe they copied PythonLabs this fast! Or are we both copying somebody else? -- Two witches watch two watches. Which witch watched which watch? Nicola Larosa - nico@tekNico.net