I've been using FFK a lot, and I've found a few hard-to-use issues with
it. For example, it isn't possible to access the transaction object in a
validator, pass parameters into it from the servlet, etc. The code makes
assumptions that are not quite right--e.g., static implies hidden (or was
that the other way around; can't remember), etc.
I've hacked in some bug fixes and modified the code here and there to
remove some of the assumptions in the code. But, at the end of the day,
Ian is right, it is time to move on from FFK and start afresh--the code is
just too hard to maintain in its present form.
I understand that Ian is working on a replacement, one that ties FFK more
closely to SQLObject. This is a natural thing if you're using SQLObject,
as I've found out in something that I'm working on now.
However, I feel that there's definitely a need for a form handing system
in Webware, one that ties in a bit more closely to the standard Webware
servlet action handling method, but is not tied closely to any particular
I've not yet had a chance to use FormKit, so I don't know if it would be a
good candidate for being the standard forms system. Thoughts or comments?
From: Ian Bicking <ianb@co...> - 2003-09-21 18:57:20
On Sunday, September 21, 2003, at 10:34 AM, elian@... wrote:
> I've been using FFK a lot, and I've found a few hard-to-use issues with
> it. For example, it isn't possible to access the transaction object in
> validator, pass parameters into it from the servlet, etc.
This is something I specifically changed with FormEncode's validation.
Basically every validation method takes a "state" parameter, which is a
simple container that is application-specific (in a web application it
would carry the transaction, in SQLObject it carries the SQLObject
> I understand that Ian is working on a replacement, one that ties FFK
> closely to SQLObject. This is a natural thing if you're using
> as I've found out in something that I'm working on now.
I'm not planning to tie it to SQLObject, though SQLObject uses the same
validation which makes it easier. More specifically, I plan to use
interfaces (specifically PyProtocols,
http://peak.telecommunity.com/PyProtocols.html , mostly because it's
the best documented), and you'll adapt a object or class to a
validator. Actually, it would have to be more than just a validator --
it would be a sort of model: validator, data source, and means of
setting data all in one. So it should be relatively easy to add this
to any object, including objects that you didn't write (since adapters
can be written by third parties).
Of course, then this becomes some sort of object-publishing system,
which wasn't what I was really expecting to make...
From: Edmund Lian <elian@in...> - 2003-09-22 02:51:24
Ian Bicking wrote:
> I'm not planning to tie it to SQLObject, though SQLObject uses the same
> validation which makes it easier. More specifically, I plan to use
> interfaces (specifically PyProtocols,
Very interesting... I'll have to take a look at Peak--never heard of it