Re: [Zope-dev] PHP vs Zope cost benefit

[Phillip J. Eby]

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'.  :)



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Leonardo Rochael Almeida]

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.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

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 .
>
> --RDM

-- 
Jason Spisak
Marketing Director, Lycoris
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[R. David Murray]

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 .

--RDM



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Leonardo Rochael Almeida]

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.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[R. David Murray]

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



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Nicola Larosa]

> 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 - [EMAIL PROTECTED]




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Joseph Cheek]

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!  [EMAIL PROTECTED], www.lycoris.com
Lycoris Desktop/LX: the familiarity of Windows, the power of Linux
+1 425 869-2930 voice, +1 425 671-0504 fax





___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

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)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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Derek Simkowiak]

-> 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



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Oliver Bleutgen]

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








___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

Dirk,

One more quick question about application/business logic in one 
place and layout in another.  

Looking at ZPT, I still see expressions and condition 
statements in the Templates themselves.  That's not really 
separation, it's just making it work with HTML editing tools.  
I'm curious is anyone can explain the true separation of 
business logic and presentation a bit better that exists with 
Zope now.  I've built quite a few DTML heavy apps, and that 
separation wasn't there.  

On Tuesday 23 April 2002 11:24 am, you wrote:
> Hi Jason,
>
> what about a mix content-management-system and
> application-server in one server:
> -> Zope + EasyPublisher
>
> you have a special layout. realizing that in php means
> editing php with html.
> with zope you can make application logic here and layout
> (presentation logic) there.
>
> you have lots of unique structured content:
> you can seperate the database logic from html very simple
> you have no limitations on the underlaying database engine,
> just remove the db-connector and put a new one in.
>
> we currently plan out new intranet with zope.
> had php content-management as an alternative, but we can't
> give php to our users.
>
> question you should answer to your self: which users have to
> work with your system in your company ? which user change
> things in the system ?
>
> Jason Spisak schrieb:
> > 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
> > [EMAIL PROTECTED],
> > http://www.lycoris.com
> > Desktop/LX: Familiar. Powerful. Open.
> > +1 425 869-2930 voice, +1 425 671-0504 fax
> >
> > ___
> > Zope-Dev maillist  -  [EMAIL PROTECTED]
> > 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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

Thanks Lennart,

There is OO php now, which they seem to enjoy.  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" <[EMAIL PROTECTED]>
>
> > 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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Lennart Regebro]

From: "Jason Spisak" <[EMAIL PROTECTED]>
> 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.




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

Dirk,

Thanks for that.  By 'separation' I'm assuming you mean ZPT, 
correct?  I'm new to that, but the virtues seem to be simple 
edit and save for layout folks.

With PHP, you can create forms to publish content.  You don't 
have to give content mamagers PHP.  Zope's a win for Designers, 
for sure.  Right now the designers are the coders, so that's 
more like an 'eventual' win.

The database logic can be separated with PHP by just creating 
some php 'backend stuff'  and calling those database functions 
you've created from the 'presentation' scripts.  Just like 
calling a ZSQL method from a DTML method.   As long as you kept 
the exposed calls the same, you could change Databases.  It 
probably wouldn't be as easy to step to Oracle if they wanted 
to.  You are right about that! ;-)


On Tuesday 23 April 2002 11:24 am, you wrote:
> Hi Jason,
>
> what about a mix content-management-system and
> application-server in one server:
> -> Zope + EasyPublisher
>
> you have a special layout. realizing that in php means
> editing php with html.
> with zope you can make application logic here and layout
> (presentation logic) there.
>
> you have lots of unique structured content:
> you can seperate the database logic from html very simple
> you have no limitations on the underlaying database engine,
> just remove the db-connector and put a new one in.
>
> we currently plan out new intranet with zope.
> had php content-management as an alternative, but we can't
> give php to our users.
>
> question you should answer to your self: which users have to
> work with your system in your company ? which user change
> things in the system ?
>
> Jason Spisak schrieb:
> > 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
> > [EMAIL PROTECTED],
> > http://www.lycoris.com
> > Desktop/LX: Familiar. Powerful. Open.
> > +1 425 869-2930 voice, +1 425 671-0504 fax
> >
> > ___
> > Zope-Dev maillist  -  [EMAIL PROTECTED]
> > 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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

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)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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[William Trenker]

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)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

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

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/linuxjournal29.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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

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)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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[Oliver Bleutgen]

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/linuxjournal29.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;
 }
 }
}




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

Re: [Zope-dev] PHP vs Zope cost benefit

[William Trenker]

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)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

Re: [Zope-dev] PHP vs Zope cost benefit

[Jason Spisak]

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  -  [EMAIL PROTECTED]
> 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
[EMAIL PROTECTED], 
http://www.lycoris.com
Desktop/LX: Familiar. Powerful. Open.
+1 425 869-2930 voice, +1 425 671-0504 fax


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )

RE: [Zope-dev] PHP vs Zope cost benefit

[Steve Drees]

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

Is this really ture for anything non-trivial?


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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 )