Concepts of Pylons (proposal for an introductory article to web frameworks)
Christoph Haas
my background is 10 years of Perl CGIs and only 2 years of Python. Pythons
CGI support is pretty ridiculous so I considered using web frameworks
although I generally don't like too much magic. It took a while until I
got acquainted with that approach. Now that I think I get the idea and am
already working on a larger application in Pylons I though I'd write down
some notes for other people like me who could use that guidance. The
result is a proposal for a document on pylonshq.com that I gave the
working title "Concepts of Python". Please find it at
http://workaround.org/concepts-of-pylons.html
It's of course available in ReST format and as soon as I get a place to put
it for further public review I'll upload the ReST source. Let me know what
you think. The document surely needs some work as I'm not a native speaker
and some of my views may not be completely technically correct. Especially
the attempt of a comparison of Django, Turbogears and Pylons is very
daring. :)
Kindly
Christoph ("Signum" on IRC)
Graham Higgins
Hash: SHA1
On 28 Jan 2007, at 20:03, Christoph Haas wrote:
> http://workaround.org/concepts-of-pylons.html
Good effort. FWIW I commend you on your English skills and (broadly)
your comparison of Django, Turbogears and Pylons .
> The document surely needs some work as I'm not a native speaker
> and some of my views may not be completely technically correct.
I have some language adjustments. How you do you want them delivered,
as a patchable diff?
Cheers,
Graham.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iQCVAgUBRb0JpVnrWVZ7aXD1AQJWIAP/W7a3AdMk62qZI+zAVKCcZpBRmeoZ+FrK
1TbsqtJ9qDOMqlqb/IsAL40r3P6RxILj/0bkQ7A931VlE07qexLUxoRb6J/Mij9g
NV7YdMEocwLGSFetYpPu7ovkKqgVIMXktjuQU0DV1Y9eAwwPJNi89X6zMSm7qZeX
0ZMGE7eyHFY=
=w52+
-----END PGP SIGNATURE-----
Chris Shenton
approaches and frameworks. I wish I had your document when I started
working with Pylons to get the big picture.
Thanks!
Christoph Haas
> On 28 Jan 2007, at 20:03, Christoph Haas wrote:
> > http://workaround.org/concepts-of-pylons.html
>
> Good effort. FWIW I commend you on your English skills and (broadly)
> your comparison of Django, Turbogears and Pylons .
Thanks. It's really hard to compare the three beasts. And most of the
comparisons I read on the web are pure FUD, too.
> > The document surely needs some work as I'm not a native speaker
> > and some of my views may not be completely technically correct.
>
> I have some language adjustments. How you do you want them delivered,
> as a patchable diff?
Thanks for the feedback, Graham. I decided to move the document to
http://pylonshq.com/project/pylonshq/wiki/ConceptsOfPylons so everyone can
edit it. (Fortunately the trac wiki seems to have a 'ReST' rendering
module.) It's not yet linked from anywhere but once we agree upon it
perhaps someone who's in charge of the "Documentation" part of
pylonshq.com can link it later.
Feel free to edit it.
Kindly
Christoph
Graham Higgins
Hash: SHA1
On 28 Jan 2007, at 21:00, Christoph Haas wrote:
> Thanks. It's really hard to compare the three beasts.
I am running commercial sites developed in both Django & TG, and I've
pushed Pylons around a bit. Your characterisation of the three
different approaches agrees broadly with my experience. I think the
case for Pylons is perhaps a little underplayed although I fully
appreciate your effort after objectivity.
> And most of the comparisons I read on the web are pure FUD, too.
In order to get a good appreciation of the key issues, it is
necessary to go some way beyond the "hello wiki" tutorials and auto-
generated CRUD. For example, you mention the nuances of different URL
dispatch approaches, this is an issue which doesn't really come into
play until more complex apps are developed and most of the
comparisons are based on apps which don't afford that deep a level of
analysis.
> I decided to move the document to
> http://pylonshq.com/project/pylonshq/wiki/ConceptsOfPylons so
> everyone can
> edit it.
> Feel free to edit it.
That's extremely collegial of you. For now, I've confined myself to
polishing the English (didn't need much). I have some substantive
changes to propose but I shall email you offlist with suggestions.
> It's not yet linked from anywhere but once we agree upon it
> perhaps someone who's in charge of the "Documentation" part of
> pylonshq.com can link it later.
Is there a "designate"?
Cheers,
Graham.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iQCVAgUBRb0zMVnrWVZ7aXD1AQKKMAQA0mfNEPxWlqBrdAspacnUgEJrrslZ988U
QpXjJ7cQwragq2JU1MBDiqYulS8j6jgrLa7DN5C6y1c2z8dmRneGPR9yQWzoJH4U
UfLwTWIt3JUyruF2m7yF2ragTk233H9hcYY3DqpAOI7g6GxpIWMNVYJv0krpFaR8
GlfZGc1uVmw=
=q/rB
-----END PGP SIGNATURE-----
Christoph Haas
> On 28 Jan 2007, at 21:00, Christoph Haas wrote:
> > Thanks. It's really hard to compare the three beasts.
>
> I am running commercial sites developed in both Django & TG, and I've
> pushed Pylons around a bit. Your characterisation of the three
> different approaches agrees broadly with my experience. I think the
> case for Pylons is perhaps a little underplayed although I fully
> appreciate your effort after objectivity.
As you have way more experience with Django and TG then me (I merely worked
through the tutorials and created a small test application to get a feel
for both systems) I appreciate any experience from real-life projects.
> > I decided to move the document to
> > http://pylonshq.com/project/pylonshq/wiki/ConceptsOfPylons so
> > everyone can
> > edit it.
> >
> > Feel free to edit it.
>
> That's extremely collegial of you. For now, I've confined myself to
> polishing the English (didn't need much). I have some substantive
> changes to propose but I shall email you offlist with suggestions.
Don't worry. I'm not easily pissed. The reason I started the article
is not to have my name on yet another boring article on the internet but
rather provide some help for people not yet experienced with web
frameworks. Just like Chris Shenton said it's nice to get the big picture
before diving in. Many people have real-life projects on their todo list
and need to decide quickly on where to start. I was afraid I'd start with
Django and then rewrite everything after half a year when I discovered
it's not for me so I spent some time finding the "right way" (tm).
> > It's not yet linked from anywhere but once we agree upon it
> > perhaps someone who's in charge of the "Documentation" part of
> > pylonshq.com can link it later.
>
> Is there a "designate"?
I'm not yet familiar with the project structure. I know that Ben Bangert is
the main driving force behind the project. But there are probably other
people involved as well in e.g. maintaining the documentation. All I found
was "ask on the mailing list if you want to contribute"? Is there a review
process? Does the documentation get checked into the svn? After all the
main documentation that you get when you click on the "Docs" link is not
part of the wiki and seems to needs an admin. Who gets access and who
grants access? Until then we have no other chance than to keep it in the
wiki.
Cheers
Christoph
James Gardner
I think your introduction is very helpful so thanks for writing it up.
I've added a note to the TowardsOnePointZero page that we should add
something similar to the main docs.
> Is there a review
> process? Does the documentation get checked into the svn? After all the
> main documentation that you get when you click on the "Docs" link is not
> part of the wiki and seems to needs an admin. Who gets access and who
> grants access? Until then we have no other chance than to keep it in the
> wiki.
Ben, myself and Philip Jenvey have written most of the main project
docs. They are stored in subversion here and any of the main developers
have access to update them:
http://pylonshq.com/project/pylonshq/browser/Pylons/trunk/docs?order=name
The usual process is that documentation starts of life on the wiki (with
discussion on the mailing list or IRC) and then one of us takes all the
concepts and puts them together for inclusion in the main docs.
Cheers,
James
Mike Orr
this tutorial and in Pylons tutorials generally.
Some of the points I raise below have already been corrected by Christoph.
--Mike
---------- Forwarded message ----------
From: Mike Orr <slugg...@gmail.com>
Date: Jan 29, 2007 12:07 PM
Subject: Re: Concepts of Pylons (proposal for an introductory article
to web frameworks)
To: Christoph Haas <em...@christoph-haas.de>
Hi Christoph! Reading over the Concepts of Pylons tutorial.
http://pylonshq.com/project/pylonshq/wiki/ConceptsOfPylons
Excellent tutorial idea, and it even answers the MVC question somebody
had earlier. It's also good that you provide convenient links to each
component's full docs. You also start to answer the question "How to
choose an HTTP server?" and touch on "How to choose a template
system?" and "How to choose between SQLObject and SQLAlchemy?" These
are all needed: the docs say how to implement these but not how to
evaluate them.
I have some wording updates but I don't have time to do them right
now. Here are a few things that caught my eye:
Section "What does MVC mean?"
- First two paragraphs overlap; should be combined into one.
- "Models do not contain any information about the meaning of this data."
What do you mean by 'meaning'? The model *does* know the meaning of
the data, that's its purpose. If you have a set of baseball scores
and you want batting averages, you call a function in the model. You
don't call something in the view or controller because they don't know
what a batting average is or how to calculate it.
The issue is whether it's a generic piece of "business logic" for
any application, or something specific to this application. If it's
generic it belongs in the model. If it's specific to this
application, it belongs in the controller.
- "The idea of MVC though is that you can work on one part without
breaking other parts."
Not just work on, but interchange. You can plug in a different
template system or database back-end, without having to rewrite the
application from scratch.
Section "Paste"
- Needs an actual example of a config file (there's one in
http://pythonpaste.org/script). If I've never seen the config file
before I'd be lost in the details, especially if I don't know what INI
format means. People are not going to go to another page and read all
the details just to answer these basic questions.
Section "SQLAlchemy"
- object relational mapper -> object-relational mapper
(because "object relational" is a single concept that modifies
"mapper". Otherwise it looks like "A modifies B modifies C". The
difference is most striking in "twenty-odd people" (approximately
twenty people) vs "twenty odd people" (twenty people who are strange).
- The SQLAlchemy vs SQLObject issue is too big for an
overview-tutorial aimed at total newbies. I'd either delete the
paragraph, or just mention that SQLObject exists and link to a page
describing the differences and how to choose between the two. My main
objections to SQLObject aren't even in this paragraph. But conversely,
the paragraph makes many unsubstantiated claims against SQLObject. To
really deal with this properly you'd have to explain why SQLObject is
easier (or is perceived to be easier), how it's "less explicit", and
why the query syntax is "strange". That's too much for this short
tutorial, so it would have to be on a separate page.
Section "Myghty"
- In the introduction you mention Mako but here you describe Myghty.
This is understandable since Pylons is in transition, but the tutorial
reader will be confused. I'd say something like, "Pylons is moving
from Myghty to Mako, but they are both pretty similar, here's how they
work..."
Section "Routes"
- Suggest rewording first paragraph to: "An interesting aspect of web
frameworks is that you completely control what happens with the data
the user sends you. This includes the URL itself. Routes lets you
choose which action should happen for a particular kind of URL...."
- Delete "by the way", or put a comma before it.
Section "Webhelpers"
- "The Webhelpers" -> "Webhelpers"
Section "Are there any other web frameworks?"
- Great text, just needs some rewording. I'll get to it when I have time.
One thing to decide is how many choices to give people. You mention
SQLObject vs SQLAlchemy, but not Paste HTTP server vs others. I don't
know which way is "right", but one needs to think about this overall:
"In which cases is it really important to mention the alternatives?"
This will be a highly-read Pylons article, so thanks for writing it.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
> On Monday 29 January 2007 21:07, you (Mike Orr) wrote:
> > - "Models do not contain any information about the meaning of this
> > data." What do you mean by 'meaning'? The model *does* know the meaning
> > of the data, that's its purpose. If you have a set of baseball scores
> > and you want batting averages, you call a function in the model. You
> > don't call something in the view or controller because they don't know
> > what a batting average is or how to calculate it.
>
> contains data like `batter` and `hits` but the model isn't supposed to
> make any sense of that. Assigning that information to a real-life concept
> doesn't seem to be part of the model. I can't really say much about it.
The Wikipedia entry does allow the model to be smart.
"Domain logic adds meaning to raw data (e.g., calculating if today is
the user's birthday, or the totals, taxes and shipping charges for
shopping cart items)."
http://en.wikipedia.org/wiki/Model-view-controller
Perhaps I misunderstand MVC, but I find my way very useful.
> > - "The idea of MVC though is that you can work on one part without
> > breaking other parts."
> > Not just work on, but interchange. You can plug in a different
> > template system or database back-end, without having to rewrite the
> > application from scratch.
>
> Right. That should be clarified. Although in the MVC theory all the three
> parts are independent. Of course that won't work in Pylons because if I
> change the 'M' I need to take care of that in the 'C'. Whether I use MySQL
> or PostgreSQL is surely not important for the 'C' but the definition of
> the 'M' is.
The model does not have to be SQLAlchemy itself. The model can be a
higher-level front end. Then you can replace SQLAlchemy with another
type of database (maybe Durus) without changing the controllers.
I make a higher-level model that answers "business queries". My
chemical database site doesn't allow access to the database directly;
there's an intermediate class with methods for:
iter_all_chemicals() => yield Chemical
get_chemical(id) => Chemical
get_chemical_name(id) => string
predict_reactivity(list of ids) => ReactivityResult
Every business concept required by the application gets a method. But
if a group of methods can be represented by a primitive Python type
(e.g., a list), I just expose the type directly.
My Chemical type is purposely database-independent. Since my database
is read-only, I only have to fill it one way. Obviously, one could
choose to expose the SQLAlchemy objects directly.
--
Mike Orr <slugg...@gmail.com>