Fergus Doyle wrote:
> I also normally set up a bunch form fields as template macros and then
> write a template for each form pulling the widgets together (allowing
> for default values and errors to be displayed in a standard way)
> instead of using a form generation utility. I find it allows for much
> greater flexibility if you are dealing with highly stylised /
> customised forms throughout a project.
Yup, the KARL project was using FormEncode (and repoze.enformed) until
recently. It works well for smaller projects, but as things got more
complicated, it turned out that the template macros and the form fields
pulling them together were evolving into a form generation package, and not a
very good one. So the decision was made to switch to Formish, since it sucks
less than the ad-hoc form generation that was happening.
KARL is a bit of a beast, though; for smaller projects (read: most of them)
FormEncode and manual form templating is a fine idea.
> On 30 Apr 2010, at 01:40, Darryl Cousins wrote:
>> I happily use FormEncode with BFG.
>> On Thu, Apr 29, 2010 at 10:23 AM, Rob Miller <r...@kalistra.com> wrote:
>>> Chris Withers wrote:
>>>> Hi All,
>>>> Is there anything akin to Django's form generation and handling
>>>> that's recommended for use with BFG?
>>> repoze.bfg.formish is probably your best bet right now:
>>> it's being used pretty heavily by the KARL project, so there's lots
>>> of in-use
>>> code to look at, the <formish:form> tags (and the classes they
>>> refer to) in
>>> this file are a good place to start:
>>> chris has been working on repoze.deform, which is similar in many
>>> ways to
>>> repoze.bfg.formish, but takes a different approach to
>>> serialization, along w/
>>> some other differences. see:
>>> the deform stuff is much less battle-worn, however; not only has
>>> repoze.bfg.formish been around for longer, but formish itself has a
>>> life of
>>> its own outside of repoze-land, whereas i'm not sure if deform has
>>> even seen
>>> any production use yet.
Repoze-dev mailing list