text: -----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?
  - --+4spJWgwF3QvpWNwRAp9hAJ9R/eXSdhIJ/4g0x0mYOeWEMD6qhwCfZOVv
  HJD8G8mUY8fNeyW50PlMEeM=
  =nfz+
  -----END PGP SIGNATURE-----