Webware for Python

Matt Feifarek wrote:
> We've released an alpha of FormKit, our form processing and generation
> library for python, with extensive webkit support.
> 
> Further info in the Google group:
> http://groups-beta.google.com/group/FormKit4Python

Have you guys thought about using FormEncode's validation instead of the 
older API from FunFormKit?  It includes things like passing around 
custom state (so you can call back into the servlet from a validator), 
better customization of error messages, bidirectionality of converters, 
and common overrides on all validators (if_invalid, if_empty, 
not_empty).  It also has a bunch of extra validators.

-- 
Ian Bicking  /  ianb@...  /  http://blog.ianbicking.org

Not specifically, no. I am not very familiar with your library, but
I'm certain that we're open to the idea.

We did quite a bit of overhaul on Validators/Converters this time
around, but it's possible (likely) that your library is more
sophisticated.

Also, we're hoping to make FK more useful to people who are not using
Webkit (like the Subway people). As a part of this, we're hoping to
include or bundle facilitating code, rather than hard-wire FK to any
particular framework; perhaps we could include FormEncode support this
way (as a plug-in)?


On Mon, 28 Feb 2005 17:37:11 -0600, Ian Bicking <ianb@...> wrote:
> Have you guys thought about using FormEncode's validation instead of the
> older API from FunFormKit?  It includes things like passing around

Matt Feifarek wrote:
> Not specifically, no. I am not very familiar with your library, but
> I'm certain that we're open to the idea.
> 
> We did quite a bit of overhaul on Validators/Converters this time
> around, but it's possible (likely) that your library is more
> sophisticated.
> 
> Also, we're hoping to make FK more useful to people who are not using
> Webkit (like the Subway people). As a part of this, we're hoping to
> include or bundle facilitating code, rather than hard-wire FK to any
> particular framework; perhaps we could include FormEncode support this
> way (as a plug-in)?

I don't think it could be a plugin, unless there was some common API; 
and if there's a common API then I don't know what real reason there 
would be to substitute something else.  Well... maybe that's not 
entirely true.  Really the only part that the form processor would have 
to know about is the validation, the result of the conversion, and the 
errors.  For FormEncode's validators that's just:

try:
     converted_value = validator.to_python(original_value)
except Invalid, e:
     error_message = str(e)

The state argument is optional, but could be added to to_python.  Then 
there's an API for creating validator objects, but the rest of the 
framework really doesn't need to know about that; so there could be 
meaningful alternate implementations that provide some benefit on that 
end, while providing the same interface on the other end.

-- 
Ian Bicking  /  ianb@...  / http://blog.ianbicking.org

Right, right.

I confused myself. You were speaking specifically about the validation
layer in FormEncode, and I confused that with FE in its entirety.

We're certainly open to improving the validation constructs in FK. I
need to look at your library at some point soon.

I know from your blog (which I enjoy, thanks) that you're not into
form tag generation. We're not ready for that yet, but I sympathize.
Should people need tag generation, I doubt that there is anything much
better than FormKit. Perhaps that's all Subway needs?


On Mon, 28 Feb 2005 21:01:28 -0600, Ian Bicking <ianb@...> wrote:
> I don't think it could be a plugin, unless there was some common API;
> and if there's a common API then I don't know what real reason there
> would be to substitute something else.  Well... maybe that's not
> entirely true.  Really the only part that the form processor would have
> to know about is the validation, the result of the conversion, and the
> errors.  For FormEncode's validators that's just:

Matt Feifarek wrote:
> Right, right.
> 
> I confused myself. You were speaking specifically about the validation
> layer in FormEncode, and I confused that with FE in its entirety.

FormEncode's identity is a little mixed up.  In many ways I'm really 
throwing away most of FormEncode except for the validation

> We're certainly open to improving the validation constructs in FK. I
> need to look at your library at some point soon.
> 
> I know from your blog (which I enjoy, thanks) that you're not into
> form tag generation. We're not ready for that yet, but I sympathize.
> Should people need tag generation, I doubt that there is anything much
> better than FormKit. Perhaps that's all Subway needs?

I don't mind form tag generation -- I just think it's unreasonable to 
*require* form tag generation.  Generators are a great way to create 
quality forms without a lot of effort.  But a system that creates the 
tags for the form, and simultaneously fills in attributes like "value" 
and puts in error messages, is putting too much stuff together (IMHO); 
there's a good chance you'll want to replace the generator someday 
(maybe not, but a chance), and you shouldn't have to reimplement the 
other parts of the system at that point.

-- 
Ian Bicking  /  ianb@...  /  http://blog.ianbicking.org

I see your point.

While in FK these functions are packaged in the same library, there's
not much "together" in the actual logic. Basically, we have some
tag-building (string building) stuff and then some data validation
stuff. And some glue to hook it to webkit.

Either one could be removed and used, in theory. I need to think about
how hard that would really be.

What kinds of thing would people like to see? For example, does Subway
(or webkit or whatever) want tag-building purely?

Our challenge to ourselves was to make HTML forms (which SUCK SUCK
SUCK) as OOPy as possible via python. We find such an approach useful.


On Thu, 03 Mar 2005 15:40:09 -0600, Ian Bicking <ianb@...> wrote:
> I don't mind form tag generation -- I just think it's unreasonable to
> *require* form tag generation.  Generators are a great way to create
> quality forms without a lot of effort.  But a system that creates the
> tags for the form, and simultaneously fills in attributes like "value"
> and puts in error messages, is putting too much stuff together (IMHO);
> there's a good chance you'll want to replace the generator someday
> (maybe not, but a chance), and you shouldn't have to reimplement the
> other parts of the system at that point.

I see your point.

While in FK these functions are packaged in the same library, there's
not much "together" in the actual logic. Basically, we have some
tag-building (string building) stuff and then some data validation
stuff. And some glue to hook it to webkit.

Either one could be removed and used, in theory. I need to think about
how hard that would really be.

What kinds of thing would people like to see? For example, does Subway
(or webkit or whatever) want tag-building purely?

Our challenge was to make HTML forms (which SUCK SUCK SUCK) as OOPy as
possible via python. We find such an approach useful.


On Thu, 03 Mar 2005 15:40:09 -0600, Ian Bicking <ianb@...> wrote:
> I don't mind form tag generation -- I just think it's unreasonable to
> *require* form tag generation.  Generators are a great way to create
> quality forms without a lot of effort.  But a system that creates the
> tags for the form, and simultaneously fills in attributes like "value"
> and puts in error messages, is putting too much stuff together (IMHO);
> there's a good chance you'll want to replace the generator someday
> (maybe not, but a chance), and you shouldn't have to reimplement the
> other parts of the system at that point.