Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Web development with Python 3.1

Reply
Thread Tools

Re: Web development with Python 3.1

 
 
Albert Hopkins
Guest
Posts: n/a
 
      10-28-2009
On Wed, 2009-10-28 at 15:32 +0200, Dotan Cohen wrote:
> > def index(request):
> > unmaintanable_html = """
> > <html>
> > <head>
> > <title>Index</title>
> > </head>
> > <body>
> > <h1>Embedded HTML is a PITA</h1>
> > <p>but some like pains...</p>
> > </body>
> > </html>
> > """
> > return HttpResponse(unmaintanable_html)
> >

>
> And if I need to add a variable or three in there? Static HTML I can
> do without Python.
>


Put the variables in a dict and then return

unmaintanable_html % varDict

Or, if you want the the static HTML in a file then you can return

open(static_html_filename).read() % varDict

Add any complexity beyond that though and you're pretty much on your way
to writing a template engine

-a


 
Reply With Quote
 
 
 
 
Rami Chowdhury
Guest
Posts: n/a
 
      10-28-2009
On Wed, 28 Oct 2009 14:15:54 -0700, Dotan Cohen <(E-Mail Removed)>
wrote:

>> What do you mean by "in the middle of the page"? Do you mean, for
>> instance,
>> the behavior of "middle.php" in the following PHP example:
>>
>> <?php
>>
>> include_once("beginning.inc.php");
>>
>> include_once("middle.php");
>>
>> include_once("end.inc.php");
>>
>> ?>
>>
>> Is that what you are after?
>>

>
> Yes, that is what I am after. For instance, if one were to look at the
> source code of http://dotancohen.com they would see "<!-- / HEADER
> -->". All the HTML up to that point was output by bigginin.inc.php.
> Similarly, near the end exists "<div class="bottomfiller">", all the
> code from there is generated by end.inc.php. These two files are
> included in every page of the site.
>


I think you're misunderstanding how Python and the web work together.
Python is not PHP -- it was not designed to replace HTML, and it is in
itself not a templating language. If you would like to use Python code
embedded in HTML, the way PHP is typically used, you may want to look at
Python Server Pages
(http://www.modpython.org/live/curren...pyapi-psp.html) which are
provided by mod_python.

Just so you know (as I think this is what is causing much of the
misunderstanding here), most Python web frameworks *do not* subscribe to
the traditional model of the web, where URLs represent files on a server.
(In the case of PHP, Python Server Pages, or CGI scripts, these are
augmented files which are executed by the server, but it's the same
concept). Instead, they typically map URLs to arbitrary code.

--
Rami Chowdhury
"Never attribute to malice that which can be attributed to stupidity" --
Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
 
Reply With Quote
 
 
 
 
Albert Hopkins
Guest
Posts: n/a
 
      10-28-2009
On Wed, 2009-10-28 at 16:38 +0200, Dotan Cohen wrote:
> > return HttpResponse(unmaintanable_html % data)
> >

>
> That's fine for single variables, but if I need to output a table of
> unknown rows? I assume that return means the end of the script.
> Therefore I should shove the whole table into a variable and then copy
> that variable to the array "data"?
>

No, if you use a templating system like Django's then basically you pass
a QuerySet to your template. A QuerySet is basically a pointer to a SQL
query, for example. The templating system just knows to expect an
iterable, it can be a list of rows or it can be a QuerySet which does a
fetch from a database. No need to shove an entire table into a
variable.
>
> > - second solution: do basically the same thing with a template

> system -
> > which will give you much more power and options...
> >

>
> I will look further into the Django templates, I promise. But I would
> still like to know how to work with Python proper.


Another advantage if templates for many is that it allows programmers to
do what they do best (write code) while letting web designers do what
they do best (designing web pages) without them walking over each other
(that much).

 
Reply With Quote
 
Dotan Cohen
Guest
Posts: n/a
 
      10-29-2009
> I think you're misunderstanding how Python and the web work together. Python
> is not PHP -- it was not designed to replace HTML, and it is in itself not a
> templating language. If you would like to use Python code embedded in HTML,
> the way PHP is typically used, you may want to look at Python Server Pages
> (http://www.modpython.org/live/curren...pyapi-psp.html) which are
> provided by mod_python.
>


I see, thank you! This is what has been bothering and confusing me. I
started with HTML and added PHP later, and the PHP fit in nicely
embedded in the HTML, and even though it's now HTML embedded in PHP
the principals are the same. Python doesn't seem to work that way, and
I have been having a hard time wrapping my head around just why.


> Just so you know (as I think this is what is causing much of the
> misunderstanding here), most Python web frameworks *do not* subscribe to the
> traditional model of the web, where URLs represent files on a server. (In
> the case of PHP, Python Server Pages, or CGI scripts, these are augmented
> files which are executed by the server, but it's the same concept). Instead,
> they typically map URLs to arbitrary code.
>


I don't think that I like that idea. I will give it a fair chance,
though, now that it problem has been identified.

Thank you very much for helping me understand this important distinction.

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
 
Reply With Quote
 
Dotan Cohen
Guest
Posts: n/a
 
      10-29-2009
2009/10/29 Albert Hopkins <(E-Mail Removed)>:
> On Wed, 2009-10-28 at 16:38 +0200, Dotan Cohen wrote:
>> > return HttpResponse(unmaintanable_html % data)
>> >

>>
>> That's fine for single variables, but if I need to output a table of
>> unknown rows? ¬*I assume that return means the end of the script.
>> Therefore I should shove the whole table into a variable and then copy
>> that variable to the array "data"?
>>

> No, if you use a templating system like Django's then basically you pass
> a QuerySet to your template. ¬*A QuerySet is basically a pointer to a SQL
> query, for example. ¬*The templating system just knows to expect an
> iterable, it can be a list of rows or it can be a QuerySet which does a
> fetch from a database. ¬*No need to shove an entire table into a
> variable.


Sounds like the system is trying to outsmart the programmer here.


> Another advantage if templates for many is that it allows programmers to
> do what they do best (write code) while letting web designers do what
> they do best (designing web pages) without them walking over each other
> (that much).
>


I do see that advantage.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      10-29-2009
Dotan Cohen a écrit :
>
>>> Clearly. I was referring to stdout being send to the browser as the
>>> http response.

>> s/browser/web server/ - it's the web server that reads your app's stdout and
>> send it (as is or not FWIW) back to the client.

>
> As is, in my case. Actually, what use case is there for having Apache
> reprocess the HTML output of the script?


compression, cache, whatever...

>
>> And this "output to stdout"
>> thingie is just the ipc scheme used for CGI - there are other possible
>> interfaces between the application code and the web server.
>>

>
> Other possible interfaces between the application code and the web
> server?


Depends on the web server, obviously. With Apache you have things like
mod_python, mod_wsgi, or mod_php if you go that route.

FWIW, while I would not necessarily advise using mod_python (unless of
course you really need deep Apache integration instead of independance
from the frontal web server), reading the mod_python's manual might
teach you a lot about the processing of a HTTP request and what you can
do...

>
>>> I think I mentioned that, but I apologize for being
>>> unclear.

>> It's not that it was unclear, but that it's innaccurate. "outputting to
>> stdout" is an implementation detail, and should not be exposed at the
>> applicative code level. Dealing with appropriate abstraction - here, an
>> HttpResponse object - is far better (well, IMHO of course... - standard
>> disclaimers, YMMV etc).
>>

>
> I see. I believe that is called Dotan's Razor: a slight inaccuracy
> saves a lengthy explanation.


but also impacts your "mental map" of what's going on... You're thinking
in terms of streams and stdout, which, while not that far from actual
implementation (in the end it always boils down to bits sent over the
wires...), might not be the right level of abstraction when it comes to
application programming.

>
>> Sorry, but all I can "replace" here are the header and footer - if I want to
>> generate a different markup for the "content here" part, I have to modify
>> your applicative code. I've written web apps that way myself (some 7 years
>> ago), and still have to maintain some web apps written that way, you know...
>>

>
> Quite so, I though that is what you wanted. Yes, the HTML is
> hard-coded into the script. I am learning to abstract and even use
> object-oriented approaches, though.


You can have efficient abstraction and decoupling without resorting to
OO. Also, remember that PHP is first a templating language...

>>> I google,
>>> but cannot find any exapmles of this online.

>> Well, no one in it's own mind would still use CGI (except perhaps for very
>> trivial stuff) when you have way better solutions.

>
> What I am doing _is_ trivial.


What I saw is already complex enough to justify using better tools IMHO.
Or to make better use of the one you have.

> I understand that your goal is to
> help me. I am a hard learner: I recognize that you are teaching me the
> better way, but I need convincing as to why it is better. "Bruno said
> so" is good,


It isn't.

> but "saves you coding time down the line" is a lot more
> convincing!


Well, my POV is obviously biased - I've been doing mostly web
programming for 6 or 7 years now, and not as a hobby. When you have
several new projects to ship within a short timeline while still
maintaining older projects, you really start thinking hard about
readability, maintainability, and possible reuse. But wrt/ hard-coded
embedded HTML vs templating (even in it's simpler form), it's not a
matter of "bruno said so" - it's a well-known antipattern.
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      10-29-2009
Dotan Cohen a écrit :

(snip)
>
> Yes, I like to separate HTML from code. However, often I need to
> output something in the middle of the page. How could I do that with a
> template?


Perhaps learning to use some templating system could help ?-)

I'd personnaly suggest either Mako (possibly one of the best Python
templating systems) or Django's (well documented and beginner-friendly).

 
Reply With Quote
 
Dotan Cohen
Guest
Posts: n/a
 
      10-29-2009
>> As is, in my case. Actually, what use case is there for having Apache
>> reprocess the HTML output of the script?

>
> compression, cache, whatever...
>


Thanks. I actually did think of compression.


>>> It's not that it was unclear, but that it's innaccurate. "outputting to
>>> stdout" is an implementation detail, and should not be exposed at the
>>> applicative code level. Dealing with appropriate abstraction - here, an
>>> HttpResponse object - is far better (well, IMHO of course... - standard
>>> disclaimers, YMMV etc).
>>>

>>
>> I see. I believe that is called Dotan's Razor: a slight inaccuracy
>> saves a lengthy explanation.

>
> but also impacts your "mental map" of what's going on... You're thinking in
> terms of streams and stdout, which, while not that far from actual
> implementation (in the end it always boils down to bits sent over the
> wires...), might not be the right level of abstraction when it comes to
> application programming.
>


Seeing how the templating engines work, I now know why my choice of
words bothered you. In fact, I was thinking in terms of PHP's linear
progress through the code which is not quite valid here. Thank you for
taking the time to set me straight.


> What I saw is already complex enough to justify using better tools IMHO. ¬*Or
> to make better use of the one you have.
>


I am beginning to see how true that is.


> I'd personnaly suggest either Mako (possibly one of the best Python
> templating systems) or Django's (well documented and beginner-friendly).
>


I will examine them both this weekend. Thanks!

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      10-29-2009
Dotan Cohen a écrit :
>> What do you mean by "in the middle of the page"? Do you mean, for instance,
>> the behavior of "middle.php" in the following PHP example:
>>
>> <?php
>>
>> include_once("beginning.inc.php");
>>
>> include_once("middle.php");
>>
>> include_once("end.inc.php");
>>
>> ?>
>>
>> Is that what you are after?
>>

>
> Yes, that is what I am after.


Django's templating system has an "include" statement, but also
something you don't have in PHP : an "extends" statement. Yes, template
inheritance. This means that you can define the general basic layout for
all your site in one "base" template, and make your other templates just
fill the "blanks" you defined in the base template.

FWIW, I'm using Django has an example but quite a few other templating
systems have this "template inheritance" feature one way or another...

> For instance, if one were to look at the
> source code of http://dotancohen.com they would see "<!-- / HEADER
> -->". All the HTML up to that point was output by bigginin.inc.php.
> Similarly, near the end exists "<div class="bottomfiller">", all the
> code from there is generated by end.inc.php. These two files are
> included in every page of the site.


And ? Do you really thing we'd all be wasting time using templating
systems too dumb to do even such a simple thing ???

Perhaps this might better answer your questions:
http://docs.djangoproject.com/en/dev...templates/#id1

 
Reply With Quote
 
Dotan Cohen
Guest
Posts: n/a
 
      10-29-2009
> Perhaps this might better answer your questions:
> http://docs.djangoproject.com/en/dev...templates/#id1
>


Actually, that example just proves my point! Look at this "templating code":
{% for entry in blog_entries %}
<h2>{{ entry.title }}</h2>
<p>{{ entry.body }}</p>
{% endfor %}

Why would I want to learn that when Python already has a real for
loop? I know HTML, and I have a goal of learning Python for it's
reusability (desktop apps, for instance). I don't want to learn some
"templating language" that duplicates what Python already has built
in!

I think that I will use the HTTP-abstraction features of Django, but
disregard the templates. My code might be uglier, but the knowledge
will be transferable to other projects. My ultimate goal is not to
make the latest greatest website. My ultimate goal is to port my
perfectly functional website to a language that will benefit me by
knowing it.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Web Application development vs windows client development cabernet123@hotmail.com ASP .Net 0 11-17-2005 12:09 AM
Lisp development with macros faster than Python development?.. seberino@spawar.navy.mil Python 37 07-11-2005 02:10 PM
Web Clients, the role of ASP.NET and the Future of Web Development and Web Standards Guadala Harry ASP .Net 9 11-06-2004 03:05 AM
development environment architecture for ASP.NET development team Akhlaq Khan ASP .Net 4 09-27-2004 01:33 PM
Re: Development best practices and knowing when to exercise control over development Kevin Spencer ASP .Net 2 08-06-2003 09:33 PM



Advertisments