Webware for Python

Paul,

I like your idea of registering a WebKit forms handler and handing the data 
off to another URL. It might also make sense, in PSP-like fashion, to allow 
a form to specify a page superclass and page super method. This would 
enable form interfaces to inherit site look-and-feel like header, sidebar 
and footer.

Also, I think this is the URL you really want to hand out for xforms:

   http://www.w3.org/TR/xforms-datamodel/

It always points to the latest (which is Aug 15, not Apr 6).

Personally, I haven't taken an interest in XML-based messaging/specifying 
because I find using Python dictionaries is fast, efficient and fulfills my 
purposes wherever someone has urged me to use XML.

However, I understand some programmers want language independence and a 
"standard approach". You may have noticed that Geoff recently created an 
XMLRPCServlet class in WebKit. He was able to do so because WebKit starts 
with very abstract classes and builds up to something concrete.

Likewise, FormKit will do the same.

-Chuck


At 05:44 PM 12/12/2000 +0100, Paul Boddie wrote:
> > At 03:18 AM 12/8/2000 +0000, Tripp Lilley wrote:
> >
> > >Chuck, when you're working on FormKit, you might want to look at this
> > >for ideas. No clue whether or not they'll be good ideas :) Anyway, they
> > >use an XML format to specify the forms, validation rules, etc. You
> > >should also take a peek at XFDL, the eXtensible Forms Description
> > >Language. It's a really shitty XML format for doing forms, but it's got
> > >the W3C stamp of approval, and isn't limited to web work.
> > >
> > >         http://freshmeat.net/projects/formmagick/
> >
> > Thanks for the note. Pretty scary that I just opened up my FormKit
> > source files to continue work on it right before this msg arrived and
> > possibly while you were composing it.
>
>I've just joined the list, but I saw this in the archives. In the early 
>days of
>Webware, I was busy developing my own tools and frameworks for CGI-like Web
>development, and I was fairly interested in structured data handling with Web
>forms.
>
>Anyway, I have recently been working on an XForms [1] handler for Webware 
>0.4.1
>which attempts to read in and structure form data according to XForms
>definitions. What currently happens is that I register a handler for documents
>with the suffix ".xform" and when Webware receives a request for a 
>resource with
>that suffix, my handler reads the definition of the same name as the resource
>from the filesystem, then it attempts to structure any incoming form data
>according to that definition before handing over control to a resource whose
>name is defined as the "action" in the XForm definition.
>
>Pictorally, it looks like this:
>
>   --[data]--> resource.xform --[structured data]--> action
>
>Here, action could be anything that Webware supports, since my handler just
>forwards the request to another servlet. So, you could use XForms definitions
>with PSP, for example, although I haven't tried that yet.
>
>Anyway, that's what I have been up to. Is anyone up for it? ;-)
>
>Regards,
>
>Paul
>
>[1] http://www.w3.org/TR/2000/WD-xforms-datamodel-20000406/
>_______________________________________________
>Webware-discuss mailing list
>Webware-discuss@...
>http://lists.sourceforge.net/mailman/listinfo/webware-discuss

Chuck,

> I like your idea of registering a WebKit forms handler and handing the
> data off to another URL. It might also make sense, in PSP-like fashion,
> to allow a form to specify a page superclass and page super method. This
> would enable form interfaces to inherit site look-and-feel like header,
> sidebar and footer.

Right, so that I can "do a Zope" and allow customisation by hierarchy... sort
of.

> Also, I think this is the URL you really want to hand out for xforms:
> 
>    http://www.w3.org/TR/xforms-datamodel/

That one doesn't actually give a data model, though. ;-) Instead, they're just
telling everyone that it's not such a hot idea in that shape and form after all.
:-)

> It always points to the latest (which is Aug 15, not Apr 6).

Well, I'm using the April 6th specification as it does actually define a data
model, as I note above. Besides, it makes it clear what I'm actually working
from, even though I'm not being too accurate. ;-)

> Personally, I haven't taken an interest in XML-based
> messaging/specifying because I find using Python dictionaries is fast,
> efficient and fulfills my purposes wherever someone has urged me to use
> XML.

I don't use XML here more than to specify what kind of data the handler/servlet
is expecting. Interestingly, if one wanted to be strict about type checking in
Python itself, one would need to adopt such kinds of structure descriptions,
especially if one wanted to deal with strictly typed hierarchical structures.

Of course, there is an internal Python representation which is equivalent to
each XForm definition, but my idea is to provide a capability to separate the
type description from the handler and then use Webware to associate them. If I
could magically block direct access to the handlers then everything would be
almost perfect.

I was rather impressed that I managed to get this kind of thing working in
Webware. Just at the appropriate point in time, I found the forwarding method in
the API, so you've certainly thought this kind of thing through in advance.

> However, I understand some programmers want language independence and a
> "standard approach". You may have noticed that Geoff recently created an
> XMLRPCServlet class in WebKit. He was able to do so because WebKit
> starts with very abstract classes and builds up to something concrete.

There is some kind of overlap here, though. Ideally, one could have an XForm
definition which dictates the input specification for data coming in a number of
different ways, from standard HTML forms through to XML-RPC; the latter really
being how HTML form data should have been transmitted from the start, I suppose.

> Likewise, FormKit will do the same.

Do you have any information on FormKit on the Webware Web site? I didn't see
anything the last time I looked.

Regards,

Paul

At 04:25 PM 12/14/2000 +0100, Paul Boddie wrote:
>I don't use XML here more than to specify what kind of data the 
>handler/servlet
>is expecting. Interestingly, if one wanted to be strict about type checking in
>Python itself, one would need to adopt such kinds of structure descriptions,
>especially if one wanted to deal with strictly typed hierarchical structures.

I do similar kinds of things, but I always use comma-separate-values (CSV) 
files which I edit in a spreadsheet such as MS Excel. Of course, CSV is 
text so everyone can deal with them if they really have two.

I often have columns for name, type, min, max, isRequired, etc. I use 
MiscUtils.DataTable to read these files. I can then loop through the rows 
and treat each one like a dictionary keyed by the column names.

Also, columns can specify types like "min:int" and "max:int" so I can deal 
with the data in a "real" fashion (e.g., I don't have to invoke things like 
int() and float() all the time).


>Of course, there is an internal Python representation which is equivalent to
>each XForm definition, but my idea is to provide a capability to separate the
>type description from the handler and then use Webware to associate them. If I
>could magically block direct access to the handlers then everything would be
>almost perfect.

Not sure what you mean by "magically block access". Are you saying the URLs 
that handle the data submitted from the forms should only be "invokable" 
from the forms? If so, perhaps some kind of special identifier passed as a 
hidden field would be appropriate. Especially if these were generated from 
some kind of algorithm that would make them transient and hard to guess.

But I don't know if that's what you were referring to.


>I was rather impressed that I managed to get this kind of thing working in
>Webware. Just at the appropriate point in time, I found the forwarding 
>method in
>the API, so you've certainly thought this kind of thing through in advance.

You can thank Jay for that one. He was the champion for URL forwarding.


> > Likewise, FormKit will do the same.
>
>Do you have any information on FormKit on the Webware Web site? I didn't see
>anything the last time I looked.

No. It's gone through 2 redesigns and I didn't want to post it while it was 
pre-pre-pre-alpha. I don't have a firm timeline on it right now.


-Chuck