[Zope-dev] PHP vs Zope cost benefit
Derek Simkowiak
dereks@realloc.net
Tue, 23 Apr 2002 14:06:27 -0700 (PDT)
-> 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