On Sun, Oct 4, 2009 at 2: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. > If things were different, then different things would be done. Looking at WTForms, it looks like it is both widgets and validation, and it could use FormEncode validation largely in the same way it uses its current validation. It's always been possible to embed FormEncode in other systems, and keeping FormEncode focused strictly on validation allows for that. I can't make anyone pay attention to FormEncode, its scope, or what it does... but I can hardly get excited about development that ignores it. I'm glad Marcus is trying out different ways of handling control flow. The library I wrote before FormEncode included control flow and framework bindings, and it kind of sucked -- I left them out of FormEncode so people could wrap it however they thought best. @validate is one such wrapping, but more explicit control flow is usually much easier to understand, which is what Marcus seems to have implemented. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
