|
Geert Jansen
geert at boskant.nl
Sun Jun 8 17:35:13 EST 2003
Hi Johathan,
> 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.
A lot of good ideas, but I agree with other posters that most of them
are present in the current web application solutions.
> 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 ...
Draco has this. It provides the following classes: Field, StringField,
AsciiField, IntField, FloatField, EnumField.
> - - 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.
Draco has a Form class that does this. You add Field (sub)classes to it
in the constructor, and then call parse() on a namespace (usually, the
http GET/POST) namespace). The result is a new namespace with your
parsed args, or a FormError exception on error.
> - - 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.
Again, Draco has this, except that sessions are always enabled, not only
for specific pages. Any variables assigned to the "session" namespace
are automatically put in a db table that is bound to the current session
via a session-id (either stored in a cookie or from the URL or both).
The namespace is typed, you can put in any object that can be pickled.
Additionaly, there is the "user" namespace, containing variables bound
to the current user (if the session is logged-in), "application",
"server" namespaces, etc.
> - - 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?
I agree with you completely. My preference is also to use a pure form of
Python for loops, conditionals, etc. Another option that is used by
Albatross and Zope is that you have a 3rd language in the form of extra
tags.
> - - 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.
I think that a db-api should be part of the core of any web framework.
Draco implements a "database" object that provides access to the system
database (database that Draco itself uses too for session data, etc).
This object implements methods to get new cursors, open transactions,
etc. An object oriented, namespace like API for
querying/adding/modifying tables and records should be available too. I
have this but it's rather immature so I did not yet add it to Draco.
> - - 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
I'm not a big fan of these because generating html from code makes the
separation of the job of the web designer and the programmer more
difficult. Draco implements "tag rewriting" that transparently plugs
back form variables into the html. This at least alleviates the problem
because the html can be pure, and doesn't need any code for form
feedback.
> 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?
Without too much shameless self promotion I think that Draco is pretty
close to a killer web application framework. It just needs some more
developers and users to see how it performs for a broad audience and to
improve it accordingly. I am willing to do concessions to make it better
and more accepted. My time is very limited at the moment, however.
Cheers,
Geert
|