I think the "field enclosures" part of WTForms handles ForEach (Not very familiar with FormEncode, so perhaps not):
http://wtforms.simplecodes.com/docs/fields.html#field-enclosures On Oct 4, 8:36 pm, Mike Orr <[email protected]> wrote: > On Sun, Oct 4, 2009 at 12:02 PM, Kevin J. Smith <[email protected]> wrote: > > > I am not so sure why everyone seems to be so unhappy with FormEncode. I > > find it a rather brilliant solution. There is definitely a steeper than > > average learning curve but like all things that are powerful and can be > > adapted to any situation, there is always a tradeoff. I would hate to see > > support for FormEncode lost in Pylons. I currently use @validate with > > custom validators and formatters with htmlfill with great success. I think > > it would be a great loss to move to some simpler solution that is not as > > powerful. The reason I chose Pylons is for its power to adapt, otherwise, I > > would have gone with Django - less learning curve but less adaptable. If > > there is going to be support added for an alternative form processing > > framework on top of FormEncode then that is great but I would hate to see > > FormEncode dropped. I know that I could always continue using FormEncode > > because Pylons is flexible but maintaining @validate on my own is not the > > ultimate situation. > > It's too late to drop FormEncode, htmlfill, and the form helpers. > We've been promising people for months that the biggest changes in > Pylons have already been done. It's one thing to drop a bad set of > helpers (the rails helpers, buggy and unmaintainable). It's another > thing to completely change the form+validation API. FormEncode > works; it's just under-documented and the code contains dead-end cruft > (i.e., useless validators). I'm just thinking that if Pylons were > being created now, WTForms might have been a better approach, and Ian > might not have written FormEncode in the first place. > > The developers have still not evaluated WTForms. I only found out > about it Friday, and I haven't tried using it in an application yet. > I'm just saying that if it proves successful, it may change future > documentation and development. I.e., mention it in the manual as an > alternative to FormEncode, and perhaps even have a tutorial for it. > The plans to update @validate and write another FormEncode manual may > be canceled. I doubt Pylons' dependencies will change. It would be > silly to depend on two form libraries, and we can't drop > FormEncode/WebHelpers because they've been promised as a part of > Pylons. If you don't use them, they're a small amount of pure-Python > code to carry around. > > If you want to take on the @validate updating, that might be possible. > The tentative plans are in the ticket. You'd just have to keep it > backward compatible or change the > name.http://pylonshq.com/project/pylonshq/ticket/405 > > -- > Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
