mike bayer <[EMAIL PROTECTED]> 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 power!
tools 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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
