[Linux dev] Re: OT: Java Programming (Again)

[Neil Blakey-Milner <nbm@xxxxxxxxxxxxxxxxxxx>]

On Wed 2003-02-12 (23:16), Mark Clarke wrote:
> 1) How does python and php prevent the maintenance nightmare of having
> scripts in the middle of your presentation logic? I.e. How do they
> separate presentation from business logic and data access. Can these
> different components be placed on different machines and interact
> successfully? i.e. are they scalable? 

Well, both PHP and Python have multiple frameworks for templating and
providing "tiered" systems.  The naive approach with PHP (much like, to
a lesser degree, Java and JSP), means you can end up with one file with
all your data access, logic, and presentation all mixed together.
Alternatives like Smarty for PHP are more in line with intelligent
templating.

Python (like Java) wasn't built for generating HTML by default, and so
you need to look at the available frameworks.  You can use PSP for an
alternative to JSP, but I think we both agree we need to go beyond that.

Zope (http://www.zope.org/) is a python-based web application
environment.  It used to have an horrid langauge called DTML for markup,
but has now moved to an advanced templating system named ZPT - Zope Page
Templates.  In basic terms, it uses (X)HTML or XML as an "example" of
how the page should look (generated in, say, Dreamweaver), and has a
language (TAL) which uses special expressions (TALES) and macros (METAL)
that is used in the XML to describe how to put the content you want into
the page in place of the dummy data.  More about ZPT at
http://www.zope.org/Wikis/DevSite/Projects/ZPT/VisionStatement

Twisted (http://www.twistedmatrix.com/) is a Python framework (and
"application server"), focussing on asynchronous I/O and event-based
(usually) networking.  As I've mentioned before, it uses a similar
method, called woven (which is also MVC), to deal with the separation of
tiers.

As with most methods, there's no real way to _prevent_ someone misusing
frameworks and chucking presentation into the logic, but the above
methods seems to make it easier to separate things.

Obviously, there are others, but these are the ones I'm familiar with
and use.

> 2) Are there really absolutely no problems upgrading php & python
> engines. Everything just runs smoothly from one version to the next?
> Aren't there conceptual breaks in approach at stages? I seem to remember
> reading an article about php finally going object orientated?

PHP's been OO (in a manner) for a while now.  PHP 5 will improve that.
One thing they're fixing, for exmaple, is passing objects by reference
by default, instead of by value.  I got slightly confused by that more
than once.

PHP's upgrade path has been a bit bumpy, but generally well-documented.
Mostly to do with configuration defaults changing for security.

Python's an absolute pleasure w.r.t. upgrading.  You pretty much don't
have to worry about upgrading python versions.  Obviously, that's the
base language, and not all the third-party modules and frameworks.

I've had more trouble with Java's third-party modules, but that's
probably because I spend most of my time with Java when someone's come
to me with a problem.

> 3) Can these languages handle things like distributed transactions,
> message queue, remote method invocation etc and all those things that we
> associate with enterprise architecture? (I assume python can.)

PHP's pretty new to acting as anything but a web-oriented language
designed to write output to a screen, and only to live for a few
seconds (at most).  It's grown quickly though, so it may be a language
in this area soon.

Python, as you assume, has all these things (in third-party modules,
building on built-in serialisation and so forth).  Twisted's a nice
framework to work with for these things, but there are others.

> Part of the problem that exists with web applications is that they use
> many different technologies like HTML,XHTML, JavaScript etc as well as
> the native language that you use to code e.g. python, java, C++ etc.
> (Basically presentation, middle tier and data access.) Also teams on
> projects have several individuals with different skills that have
> responsibility for different parts of the app. Trying to combine these
> into one language, in a coherent way , is a problem, especially if you
> have front-end people who know html/JavaScript but not php/python etc.

This is a good point.  Zope is one environment that tries to help deal
with these problems - it tries to allow developers, content providers,
graphic designers, and so forth to work together on the same site at the
same time.  I'm not saying it's still not a problem, but it's identified
the problem and suggested a solution or two (DTML, and then ZPT).  Zope
has got some really nifty features that may also help in this regard.

Zope is backed by an object database (ZODB), and this provides two
things: independent versions, and undo.

Independent versions allow someone charged with working on a Zope site
to make changes within a specific "version" of the web site.  They
switch to that "version", and make changes.  They can test as if that
"version" of the web site were live, without affecting the production
view that everyone else has.  They can then throw away their version, or
make it the new main version.

Undo means that all changes to the object database are reversible
(assuming you undo certain dependencies), meaning that if someone breaks
something, you just look in the log, and undo the change.

I gave a presentation on Zope at LinuxAfrica in 2001 (I think), I'll see
if I can dig up the presentation material.

> What I think is of growing importance in all this is the use of
> frameworks like (all jarkarta) struts, turbine, velocity and tapestry
> (if you don't like jsp). These really ease development but taking care
> of plumbing issues allow developers to concentrate on the task at hand.
> What I like about java, jakarta in particular, is that many different
> approaches are being tried.

Ah, Tapestry - that's the article I was thinking of previously.  I agree
that the Jakarta projects are absolutely vital to Java's continued
success, and for it not to suck to write many types of applications in
Java.  Twisted is one such framework for Python that takes away many of
the niggly problems, and lets you get on with the important stuff.

> Ultimately, as far as the presentation side is concerned, I think the
> Mozilla's XUL approach or cocoon and xsl-fo are the way to go for
> front-end stuff. Just define what you want in xml and let the renders
> handle the presentation for you.

Don't really care for XUL (yet?), but XML and XSL-FO are definitely
things I try and use where approriate.  And sometimes inappropriate: My
CV's a docbook-xml file with a hacked stylesheet to generate the XSL-FO
I want... I'm such a geek sometimes.

I think XML is a great storage and description (metadata) mechanism for
information that's destined to be viewed and used in multiple ways, but
I think I'd need to see a very effective example of it being used as an
intermediary in the output process for generated content.

> PS: I don't claim to be an expert in any of these technologies and know
> most only by reading about them. However these issues are what I
> consider when deciding to learn some new technology.

Same here.  Also, these are obviously just my opinions.

Neil
-- 
Neil Blakey-Milner
nbm@xxxxxxxxxxxxxxxxxxx