[mod_python] Announcement: Roadkill version 0.01 "Kitten"

Jonathan Gardner jgardner at jonathangardner.net
Sat Jun 7 22:31:53 EST 2003

Hash: SHA1

On Friday 06 June 2003 13:19, Geert Jansen wrote:
> The situation about Python web frameworks is a bit confusing and I think
> there is no "killer app" yet. However, I have a strong personal opinion
> that the standard <p> <% print "Hello, world!" %> templating systems
> don't cut it. When you create a big dynamic web site, you need something
> more powerful and on a much higher abstraction level. Creating a large
> site with a traditional ASP system is like writing a GUI word processor
> with only a setPixel() call.

Let's make the killer app, right here, right now. I am building the 
framework for my sites, and a commercial project. I know that I want to use 
mod_python because there are so many benefits to it, even above perl.

What would you suggest, within the limitations of current HTTP technology?

Some ideas I came up with are as follows. Let's discuss -- be honest about 
the ideas. You add your own.

- - Forms. It seems nice to have the code that processes the form input right 
next to the code that makes the form HTML code. This screams "put it all in 
a class!" So I came up with a few classes that should be subclassed:
	- Text input
	- Int input
	- Float input
	- Zip Code input
	... etc ...

You can do the same with the other form elements -- select, checkboxes, and 
radio buttons.

- - Groups of form elements. Sometimes I want a group of elements that go 
together. Example: Login box (name/email, password, submit), address 
(line1, line2, city, state, zip, phone) and cc info (cc #, address, name, 
etc..) I thought of having a class that does the whole thing together. You 
give it some namespace, and it puts its element in that namespace in the 
args. For instanc, if you have an address group of elements, and you give 
it the namespace "fred", then the args come back as fred.line1, fred.line2, 
fred.city, fred.state, fred.whatever.

- - Permanent and temporary sessions. Every website uses cookies for only one 
thing - sessions. We should have this built in by default. Some pages have 
it turned on, some pages won't need it and have it turned off. What happens 
is when the guy visits a page that needs a session, it sets the session 
cookie, or gets the existing one. Then it goes to the database and grabs 
the associated data, and it unserializes the data into a python object. 
Tada - you have a session. It also does some rudimentary checking to see if 
the browser has cookies turned on, redirecting them to another page if they 
do not.

- - Keeping HTML totall separate from the code is a very good idea. 
Unfortunately, it makes things like loops or iterations (like listing some 
results) difficult. I believe the best way around this is to allow some 
python code, in its pure python form, in the page somehow. However, this 
should be extremely light and only when necessary. Is there anyway around 

- - Database connection. This is something that is really important, even 
though it isn't part of the web server per se. I believe that DB-API (and 
perl DBI) just doesn't cut it because it is too low-level. There are so 
many better ways to do things. One of the biggest problems I have is 
getting data-driven SQL statement put together without taking 100 lines of 
code to do it. I found that by writing select as a function that takes 
parameters (like columns, from tables, join tables, where parameters, 
etc...) things get a lot easier. I believe we should build a system that 
has this in there.

- - Code-generated HTML. Every once in a while, we need to build our HTML 
elements manually in the code, putting every argument in precisely. This is 
annoying, and the code is always ugly. What I do is use a function that 
does it all for me. Example:
	html.select("state", (... list of states...)) -> A select list of states
	html.link(html.utl('', arg1=value1, arg2=value2), "Click here", 
class="big_link") -> a link with properly formatted arguments and all.

If we can agree on what we REALLY want, and if we take advantage of Python, 
expecially the things that make it so much more specialer than perl and 
Java, I think we can come up with THE KILLER SOLUTION. How about that for a 
project name? TKS?

- -- 
Jonathan Gardner
jgardner at jonathangardner.net
(was jgardn at alumni.washington.edu)
Live Free, Use Linux!
Version: GnuPG v1.2.1 (GNU/Linux)


More information about the Mod_python mailing list