[Tutor] Web programming advice

[Alan Gauld]

"Patrick" <optomatic at rogers.com> wrote

> is of paramount importance. It appears to me that Django is an 
> all-in-one monolithic application. Years ago Zope was the number 1 
> and now it's basically gone.

Zope is still around but it has retreated into something of a niche
where it offers its own unique advantages, namely very large,
high volume sites. Zope is, I believe, also the engine underneath
Plone which is in itself something of a niche market content
management system.

> importance I suggest that you look at Pylons/Turbogears

Thats still my personal preferred web framework although
I haven't looked at the new stuff based on Pylons.

However my experience of Web Frameworks is that they all do
the same basic things and moving from Java Struts to Ruby Rails
toTurboGears to Django has not been that hard. Once you figure
out one of them the concepts are pretty similar its just syntax
and some configuration files after that.

> programing)). This way if you do not like your framework you can 
> take much of your code with you to another framework. I don't think 
> this will be the case with Django.

The key to any kind of application building is to isolate the
application specific business logic from the presentation logic.
It should be fairtly easy to take a well cradted web application
and convert it to a GUI based standalone or vice-versa. Only
the presentation and interaction (the View and Controller of
MVC fame) need to be modified.

> You can switch out components with relative ease with Pylons and to 
> a lesser degree with Turbogears.

Which is one of the things I like abough TG, although in practice
I've never used anything but the default components!

> ORM relational mapper, you might look at SQLAlchemy
> MVC Model view Controller
> Templating engine
> WSGI
> Url Routing

The previous point about writing at least a basic Form submission
app using raw CGI is a good one too. It does force you to learn
how all of these apps work. And to understand the very real
limitations and compromises in using http/HTML as the basis of
a transaction handling system! It was never intended to do what
we are asking of it nowadays!

> Sorry to make this about me again but in my defense of my last post, 
> I really think that you do want to think about long term commitments

Thats a very good point. Tying back to my own parallels with GUIs
and OS those who picked Oberon, or BeOS or even Plan9 for their
wortld beating app are probably regretting the choice. Longevity is
a very important consideration.

> much longer. I have been thinking about learning TCL/Tk recently. It 
> has lots of benefits but it also looks like it has been in a steady 
> decline

Tcl/Tk itself is still slowly developing but the real strength of Tk 
is
the wide support it has among other scripting languages. It is a
skill that is highly portable between Tcl, Perl, Python, Lisp, Ruby, C
and probably a host of other languages. tHisis directly due to two 
things:
1) It is a very simple GUI designed primarily to wrap up existing
applications and
2) the Tcl llanguage was designed frtom the ground up to be
embedded in other languages.

> for some time. Choosing a language or a framework is in a sense a 
> business decision. I don't think that the Python framework world has 
> stabilized just yet,

In software nothing much ever stabilises. Technology changes
are the norm (with 3 notable exceptions(*)). When I started out it was
BASIC, COBOL, FORTRAN and Algol. C, Pascal and ADA were
the rising stars. By the time I was full time in programming it
was C++, Objective C and Smalltalk battling it out for the OO space.
Then Java appeared and Perl took off as a CGI tool with JavaScript
on the client. That opened the door for a plethora of scripting
languages including VB and .NET and PHP and Scheme and
of course Python... But I don't expect to be writing a lot of
Python in 10 years time. What I will be writing in is anybody's
guess...

(*)The exceptions of course are the perennial specialists:
BASIC, COBOL and FORTRAN

> consider something that decouples well.

That's sound advice

HTH,

-- 
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld