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? All my best, -- 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
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?
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
-- 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
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
I think that's a big part of it. Using something that's already documented that has many features of a 'web app' built in already, vesus scripting those. 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. On Tuesday 23 April 2002 10:47 am, you wrote:
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
-- 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
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
Curiously, if there are prepackage scripts for both, and there's less to 'mange' with PHP, that's a PHP win. I personally have CalendarTag, ZDataQueryKit and lots of yummy others runing from the downloads page. But since I'm trying to convince PHP people that using Zope is better, they just point to their yummy scripts too. 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. On Tuesday 23 April 2002 11:09 am, you wrote:
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
-- 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
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.
Thanks Lennart, There is OO php now, which they seem to enjoy. <ugh> The audited security is something I believe is big win. The quickness and efficiency of Zope Corp's (still calling them DC in my head) Zope security patching is outstanding. The community really shines there. With undoable transactions, are transactions that have taken place in the Postgres Database really undo-able by undoing the Zope transaction that made them? For users, they'll be stored in Postgres, so is LoginManager (which uses the venerably weighty ZPatterns) the best way to go, or is exUserFolder sufficient for scaling to largers numbers of users? I'll ask the Jester about that directly is no on has a quick answer. The front end user/roles permissions thing is a bit hard to manage sometimes, honestly. But it's there at least, and not in PHP unless you spend time building it. Would you not get transparent scalability by adding Apache servers to the front end that just have the same PHP scripts? As far as scaling backend Postgres Database, that's the same if you use PHP or Zope. On Tuesday 23 April 2002 11:35 am, you wrote:
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.
-- 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
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. ====
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.
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. Did I really say "broken"? ;^) -- Two witches watch two watches. Which witch watched which watch? Nicola Larosa - nico@tekNico.net
"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.
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]. joe Jason Spisak wrote:
I think Oliver's point about transaction safety is a big win. I might convince them just on that.
-- Joseph Cheek, CTO and Founder, Lycoris Redmond Linux Corp. is now Lycoris! joseph@lycoris.com, www.lycoris.com Lycoris Desktop/LX: the familiarity of Windows, the power of Linux +1 425 869-2930 voice, +1 425 671-0504 fax
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
To everyone who replied to this thread, I give a hearty congratulatory "Thank you". They have decided to allow me to mock up the app in Zope and prove it's worthiness. I'm already halfway done with the first 2 modules. ;-) 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. ;-) 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. 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. 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. Thanks again to all who responded and put on their thinking caps to help be start another project using my favorite web app of all time. Thanks, Zopistas! On Tuesday 23 April 2002 11:01 am, you wrote:
I think that's a big part of it. Using something that's already documented that has many features of a 'web app' built in already, vesus scripting those. 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.
On Tuesday 23 April 2002 10:47 am, you wrote:
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
-- 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
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
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 -- Ideas don't stay in some minds very long because they don't like solitary confinement.
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.
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
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.
On Wed, 2002-04-24 at 17:39, Jason Spisak wrote:
This means that every Update/Insert command make sthe ZODB grow, right?
Wrong. Transactions allways happen. An insert/update causes the db adapter in question to register itself for transactions, but ZODB itself won't inflate unless an object in it changes.
Has anyone had experience with Packing a site with high traffic in a case like this (RDBMS backend)? What happens?
The only thing you have to consider wrt packing is the performance impact of packing. In most cases, it's negligible. Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement.
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'. :)
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; } } }
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
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
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
-> 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. Before we get too involved in business logic vs. presentation and this thread boils down to a flame war around the model-view-controller (or model-delegate) "design pattern", I'd like to point something out. If you're using PHP or Zope (DTML/ZPT) for your "web application", then you are limited to HTML "form" inputs for your app. The bottom line is that this is good for simple database lookups/entries, but not much else. If you want a serious end-user app, you need widgets. There is no (practical) way to have a color picker, or scrollable window, or any kind of interactive animation (2D/3D), or even a decent fscking text editor (say, with syntax highlighting, or line numbers, or hotlinked tooltips) within an HTML page. (Of course there is Java and the various plugins, but this thead is about PHP vs. Zope--and the demonic GTK+ binding to PHP is server-side only :) Using the default braindead "textarea" and simple form inputs for an app is not practical for much other than providing a cross-platfrom U.I. for a database. Because those apps are generally simple (meaning, the amount of business logic involved is limited to saying what does or does not go into the database) it doesn't really matter, as far as I am concerned, which platform you use. Issues such as deployment, in-house expertise, licenses, database compatibility, and developer docs far outweigh the debate of a certain loop structure, or conditional syntax, or the ability to write a 100-line function in Python instead of PHP. I guess what I'm trying to say is that the "logic vs. presentation" argument that comes up so often is really not that important for web apps. It's the primary consideration for widget-based applications, but that is not what "web apps" are about. I'd be much more worried about things like scalability and support, because in the end, forms are forms (and they suck). --Derek
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
Not sure where Nico was quoting from but I saw my name so thought I'd comment ;-) Nicola Larosa wrote:
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.
Well, the anonymous poster was right that you don't _need_ ZPT to do that, it just makes it a hulluva lot easier. To look at it from a different point of view, it _is_ possible to mix presentation and logic badly in ZPT, it's just a lot more difficult. My take on ZPT is that it's a pretty cool way of tackling the "embedding code in HTML" problem (apparently the latest versions of ASP also have the idea of using tag attributes to store markup code) and hence I like to evangelise. I apologise if it seems I'm being a little one sided :-) cheers, Chris
(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
participants (15)
-
Chris Withers -
Derek Simkowiak -
Don Hopkins -
Jason Spisak -
Joseph Cheek -
Lennart Regebro -
Leonardo Rochael Almeida -
Myroslav Opyr -
Nicola Larosa -
Oliver Bleutgen -
Phillip J. Eby -
R. David Murray -
Stefan Bund -
Steve Drees -
William Trenker