|
Jonathan Gardner
jgardner at jonathangardner.net
Sat Jun 7 22:31:53 EST 2003
-----BEGIN PGP SIGNED MESSAGE-----
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
this?
- - 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!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+4spJWgwF3QvpWNwRAp9hAJ9R/eXSdhIJ/4g0x0mYOeWEMD6qhwCfZOVv
HJD8G8mUY8fNeyW50PlMEeM=
=nfz+
-----END PGP SIGNATURE-----
|