On Tue, Aug 30, 2011 at 9:36 AM, Ben Sizer <[email protected]> wrote: > On Aug 30, 2:42 pm, Benjamin Sims <[email protected]> wrote: >> >> The demo site provides nice examples of its capabilities: >> >> http://deformdemo.repoze.org/ > > Having explored this a little more, I must admit I find it daunting. > Sure, for simple stuff it's "easier than building HTML by hand", but > for anything non-trivial, it's hard to work out what to do, because > everything's hidden from me.
The first question is, do you have specific requirements for how the forms should look and feel, or do you just want quick functioning forms that you can prettify with CSS? The second question is, do you prefer a minimal library that keeps you close to the HTML, or an object-oriented system that generates a form in one step? These questions indicate what kind of library you'd prefer, and they also explain why there are so many vastly different form libraries. I have only used WebHelpers/FormEncode/Mako since all of my forms so far are in Pylons. and because I'm the WebHelpers maintainer so I'm quite familiar with it. :) But I do want to try Deform as soon as I have occasion to. I had mentioned earlier about making a form library comparison demo but I never got around to it. In the meantime, Ben Sims and cd34 have listed the most common alternatives. > Do people really find this easier than just emitting the HTML? If I > was doing this by hand I'd grab all the Tag objects, emit "<input > type='checkbox' name='tags' value='%d'>%s</input>" % (tag.id, > tag.name) for each one, then map those IDs back to Tags in the > response handler. That's why I asked about webhelpers, because a > function to generate that HTML for an input tag is quite handy without > obscuring the detail of what is actually going on. The advantage of WebHelpers tags is it's close to the HTML, so if you're used to making forms by hand it's an easy and flexible alternative. The helpers are more convenient than hand-coding if you happen to have a boolean variable meaning "checked", or a boolean meaning "use the multipart POST format because I have file uploads", etc. If you're shadowing a database record, check out the ModelTags object. I've never had a problem with late-binding SELECT options and the like, because the helper is called when the template is rendered, and so all the necessary state information should be available. Re the 'id' attributes, there are differences of opinion on how those should be set. WebHelpers offers one opinion by default; you can override it if your CSS or Javascript needs something else. > Although I'm grateful for the suggestions I've had so far, and have had some luck with deform, I've still not got a direct answer to this question; am I asking in the right place? Yes. All of us make forms, so all of us would benefit from discussions of the various form alternatives in Pyramid apps, and hearing how well they've worked in actual deployments. Chris M wrote: > But really the minute someone starts bumping up against styling/templating problems in Deform that seem to foreshadow a drip-drip-drip of complaints and recriminations, I usually just tell them to find something else. ;-) That's an important point, and it dovetails with my questions above. If the object-oriented form generators don't do what you want out of the box or with simple customizations, then you're probably better off with a lower-level tool. -- 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.
