From: <el...@in...> - 2003-09-21 15:35:12
|
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 backend. 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? ...Edmund. |
From: Ian B. <ia...@co...> - 2003-09-21 18:57:20
|
On Sunday, September 21, 2003, at 10:34 AM, el...@in... 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 > a > 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 instance). > 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. 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... Ian |
From: Edmund L. <el...@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, > http://peak.telecommunity.com/PyProtocols.html Very interesting... I'll have to take a look at Peak--never heard of it until now... ...Edmund. |