[Web-SIG] Re: Just lost another one to Rails

[Paul Boddie]

mike bayer <mike_mp at zzzcomputing.com> wrote:
>
>I think the term "framework" is becoming a little vague as well.
>there is the notion of "framework" as, the entire front-to-back
>approach to serve HTTP requests via Python, then there is the
>architectural approach that is used on top of an existing web API,
>and then there are templating languages which have varying degrees
>of "pluggability" into existing systems.

Yes, and I firmly believe in "unbundling" templating languages from frameworks. Perhaps it says more about me than the Python community, or more about the Python community than some other community, but it's a real turn off to look at frameworks where special hooks for some preferred template language are foisted on the developer. People have complained about stuff like how hard it is to use XML with Zope (or perhaps it was that there isn't an easy way in), and I'm sure that there are "how to" texts about working with XML in JSP, but templating should be something that developers can make their own decisions about without sacrificing 90% of the benefits of any given framework. I fondly remember the days when one had to call DTML manually in Bobo applications but still had the remotest chance of using it in other applications, and whilst I see the benefit in supporting instantaneous "hello world"-style page publishing on top of a framework, one shouldn't have to get the powertools out to make other technology choices.

>I know that I chimed in with Myghty as "well heres what I did!".
>But really, its 90% a templating language you can use with whatever
>"framwork" you want, and 10% an architectural approach which you
>can use more or less of.  In all cases it requires a web API of
>some kind and doesnt try to replace that.

I'd encourage every templating language developer to make their work as independent of any given framework as possible. As I probably said in some blog or other, plain libraries have a great record when it comes to code re-use, and to be able to cleanly integrate a templating language in an application by just importing some modules and feeding objects or functions with data, on whichever framework, would be highly beneficial for everyone concerned.

>And as far as templating languages for Python, I had a great need
>for it.  The only other powerful options for python-embedded-html
>seemed to be Cheetah and Spyce, both of which did not fit the bill
>for me.

Fair enough. No-one should be criticised for writing something which works for them. What is worrying, however, is the trend towards the proliferation of "highly excluding" top-to-bottom solutions where you buy into the whole thing and cannot easily back out of any particular technology choice without substantial re-plumbing. That there's skepticism in the Python community about Rails, which in part seems to advocate the top-to-bottom buy-in, doesn't surprise me a great deal - there wouldn't be as many different Python frameworks if people loved that sort of thing.

>I'm all for WSGI being as much of a "standard" as we should be
>embracing. But the Python community is a lot more varied than the
>Ruby one; people are thinking way out in their own boxes and have
>their preferred way of doing things (i.e. like people who only want
>to do python-generated HTML)...instead of reacting to and imitating
>the Ruby community, we should be presenting the world with our own
>community, where here are our favorite ways of doing web
>applications, but there are several varieties of how we do it.
>In the Python world, you have to use your brain a little bit.

Agreed. The emergence of WSGI seemed to signal some kind of realisation that the layers of the "Web applications stack" should be more independent and interoperable, but I think it would be more productive to pursue such an agenda at a higher level - templating and database access are areas where good solutions exist that work with as much of everything else as possible. Choice in itself isn't a bad thing as long as the decision-making process is supported by good documentation and lets people change their mind about mere implementation details.

What I'm advocating is this:

  * That the community provides narrow/thin but *completely
    separate* components/solutions which offer very well-defined
    benefits - eg. Web APIs, templating systems, database access
    layers. These things shouldn't be mixed up in the fundamental
    system on the pretense of convenience.

  * That documentation is produced to describe how one plugs these
    things into each other and how one might go about integrating
    other functionality into applications.

  * That genuine solutions for certain styles of application may be
    made, but not foisted on people from the lowest levels of any
    given system. Some applications benefit from having .myapp on
    the end of every Web resource, and by being able to write
    "hello world" in a text file and have it pumped out dynamically
    from the server; not all applications do, however.

Paul


___________________________________________________________
$0 Web Hosting with up to 200MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com