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 -~----------~----~----~----~------~----~------~--~---
