FormEncode, and FunFormKit that preceded it, have always left me indecisive and unsure. They address a problem that is fairly small -- defining forms, validation schemas, etc. But since that's a very large part of many applications, lots of people are working and thinking about these things. But FormEncode is just one project among many, and very much on the periphery of other developments, including the periphery of my own focus. I don't know what I want it to be, except that it isn't there yet, and I'm not driven to resolve that or to move forward despite that.
I tried splitting FormEncode off into a separate Validation package, which would contain just the parts I felt most comfortable about, and I have used this in some recent websites. But I'm still a little iffy about it -- it's simpler than manual form handling, but not so much simpler that it's worth it for just one project. It introduces new metaphors and concepts; for ten projects it would be simpler, because it can express certain concepts of validation more clearly than ad hoc validation code. But will it live (as it is) to ten projects?
A coworker noticed that Archetypes had split off a validation package. I'd looked at Archetypes before, but it was always so caught up in Plone and Zope that I didn't really know what to do with it -- it seemed like too much of an investment to try to figure out what the interesting parts were, and what parts were the Zopey parts that I should avoid, since they just give me a headache.
So, I start to think: do I need to cut the project loose? Maybe I should explore what I could do with Archetypes, maybe help split off larger portions of the projects. Or, if not Archetypes, then one of the other libraries -- GNU Enterprise, PEAK, Zope 3 Schemas, or one of the other projects?
Actually looking at the validation in the Archetypes package, I can't help but think that FormEncode is much better. FormEncode has a few ideas that don't seem to be common in these packages:
So it would feel like a big step back if I started working with a project that lacked some of these design features. And maybe it's not very helpful to join a project coming in with a big agenda for change. But I'm not really getting anywhere as it is, so I feel like I need to do something with the code and ideas; I'm willing to concede and compromise, but I'm not sure where to even go with that. And maybe it's just stupid to give up on a lot of code, design, and documentation.
At this point, I only care about web form validation, and I want that to be done on the client side with JavaScript and at the same time on the backend with Python once the form is submitted.
I imagine there are many ways of doing this. Something that took a config file defining the form inputs with various conditions they must meet and could turn that into the required JavaScript and Python would be nice. I'm such a simpleton when it comes to this stuff though, so I've no idea if this has been done to death already, and I don't have any experience using any of Python's various web framework thingies. I plan to do my own pyweboff soon so I can learn them.
Looking at the Validation documentation seems to make my eyes glaze over. I think I need to get more sleep or something.
FormEncode doesn't do the Javascript thing, though it's always been something I've meant to add. I've gotten a bit more experience with Javascript since then, so it might be clearer to me how to do it. It's another reason that validation requirements shouldn't be simple functions, but objects with state, with someplace to put the necessary Javascript-generating methods.
I think that at the moment the library is portrayed in the documentation (and implemented) in a general way that still requires a fair amount of bridging to use usefully in an application. The pieces are there, but I think it's still a framework issue to make them usable.
I used FormEncode for a now-on-hold project and I really liked it for the most part. Being able to nest schemas was key for me. There were a few things that could have been easier though. Note that my usage was pretty strange though.
Error reporting wasn't flexible enough for me. IIRC I ended up subclassing schema and only changing a few lines (and it made me feel sick :). I wanted to catch validation errors at the top and decide what to do with them there.
I also wanted to add a bunch of state information to the validation errors. Errors needed to be persistent and I wanted a way of refering back to the validators that failed. (The whole point of the app was to run validations on existing data and to annotate errors, we didn't want to catch them up front.)
I think I ended up passing a state object around to the different validators to accomplish all this, but I was never happy with it.
Anyhow, if any of that interests you I'd be glad to talk about it more.
I'd like to talk about it, but it should probably wait until I figure out where this discussion and where further developments should occur. I don't want to have a discussion where we're not ready to make actionable decisions, because that's just a waste of people's time, but how to make that happen is what I think I need to figure out.
I also have used Formencode off and on for a couple things but haven't yet taken the big task to use a different form validation and scheme-building package for our bread-and-butter product, a dynamic survey-building tool.
We may eventually roll our own, but we're currently using FormKit to do it all and have had to build many work-arounds to fit our needs.
I, too, would like to talk to you further about the direction of formencode and how we could participate in its development and testing.
I will be at this year's Pycon so maybe a birds-of-a-feather meeting would be great, or even a sprint on the code would be good. What do you think?
I was trying to figure out how to invoke a FormValidator (a comment in the code says it should be chained with Schema). The one that checks all the dependencies in the form and validate the whole request dictionary. We are using ZPT templates for the presentation
Thanks
# Stella Kazansky