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  /  [EMAIL PROTECTED]  / http://blog.ianbicking.org


------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss

Reply via email to