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/ECommerc
> 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 en
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 P
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.
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
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
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 mig
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 lo
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
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 su
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.
- Integrat
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 t
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
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 transa
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 misinterprete
-> 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 invol
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
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
> 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 s
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
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...(wh
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, Jaso
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
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 ex
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
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 com
26 matches
Mail list logo
