On Apr 20, 2:34 am, Ben Bangert <[email protected]> wrote: > On Apr 19, 2010, at 7:27 PM, cd34 wrote: > > > I looked at that, but, when you're developing a webapp that has 315 > > forms, that lack of automation seems to fly in the face of why I chose > > a framework. > > Framework's don't automate programming for the web, they provide a structure > around it. Frameworks and libraries provide structure and streamline common > tasks. The reason the form generation field is so full of various form > libraries is that most people have very specific needs. Even those trying to > automate it all generally take different approaches geared towards how they > need to solve it.
A form library is one of the things that I think is necessary for the way that I work. TW doesn't work the way I think -- but I do understand the theory behind its design. For me, that's a big win. > I guess I'm still confused why writing a few lines to use a few bits on a > form is so 'hard' that I need to write a bunch of Python code to have it done > for me. Is it really that tough to put a line of Mako in a form like so: > <%form:textarea name="code"/> > > Such that its much easier to go and write a toscawidgets schema and add: > class SomeForm: > code = forms.TextArea() I don't have a rational argument for preferring schema generated forms. If I used Mike Bayer's method, slowly it would morph into a schema based system even if it was passing a dictionary to mako and having mako do a bit more work. > If you know how you want the form laid out, with a table, the method Mike > shows is easy to extend to do so if you know Mako. And again, you'd have more > control, and re-use that applies directly to your use-case, rather than > attempting to force some other tool to bend to your will. > > I write quite a bit of forms, the approach is very fast and the time saved by > never having to hack away at some tool that goes through various layers of > indirection and magic to auto-generate things for me has saved waaaaay more > time than typing a little extra now and then. My previous 'framework' used mod_python/Cheetah and was very similar to Mike Bayer's approach. A form library should save me time, enforce consistent style both on the code and template side and allow a maintainer to follow up behind me, read some code/docs and be able to make changes. It should be easy enough for someone else to figure out how to modify the forms even if they don't understand the voodoo behind it. I like the fact that my schema also defines the validation on the fields. I don't have to look at the template to figure out what the field is called, how it is generated, then look at the action to figure out what validation is being done on the fields. While TW is complicated and I doubt I'll use it for another project, there are design aspects of it that I appreciate. > But given that, I can still understand your use-case, I rarely write forms > that match directly to a single table of a schema, or a single row in a > table. The apps I work on generally manipulate data that might be in multiple > tables, so no schema-based form gen tool would be of any use to me. Since you > do however generate forms directly from schema's, I'd recommend FormAlchemy > which was created for that very purpose. I have multiple projects and will use Mike Bayer's method on one of them. For the CMS I'm working on, I'm still leaning towards FormAlchemy. This is sort of the reason I asked what everyone else was using. Pylons fits my requirements very nicely, but, I wanted to make sure I was doing things in an efficient manner. -- 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.
