Comments on: Throw out your frameworks! (forms included)

By: Foxhound Design

Foxhound Design — Mon, 26 Jul 2010 01:30:39 +0000

I can’t wait for HTML5 to finally do away with frameworks. I’ll leave all the Tempita and other languages to the programming professionals like yourself. As mainly a front-end designer it’s interesting to see where the future is going with the both ends of the web and frankly it can’t come any sooner.

By: Sergey Schetinin

Sergey Schetinin — Sat, 13 Mar 2010 02:17:36 +0000

By: Tavis Rudd

Tavis Rudd — Sat, 13 Mar 2010 01:52:46 +0000

Ian, I’ve been exploring some similar thoughts regarding the need for templates languages in Python web dev. I approached the arguments for using templates with a clear mind and concluded they were mostly antiquated / invalid dogma. Here’s a little rant / example module arguing that Python developers would be much better off writing their presentation layer in plain Python: http://bitbucket.org/tavisrudd/throw-out-your-templates/ I couldn’t figure out what to name it until seeing this blog post today ;)

By: Jorge Vargas

Jorge Vargas — Sat, 06 Mar 2010 03:43:32 +0000

@Nicolas, I’ll love to see that released as Open Source.

By: Carl Meyer

Carl Meyer — Thu, 04 Mar 2010 15:54:00 +0000

That sounds like an interesting project. Except I’d have to part ways immediately with design principle #1 (the rest are excellent). If you accept schema-definition as a mental model for what your form toolkit is doing (clearly some don’t prefer it), declarative classes are a natural and intuitive way to declare a schema. And why shouldn’t schema-definition to be a static module-level concern?

Nor am I concerned about intermingling code and data; in fact I think the less distinction there is between the two, the better.

By: Nicolas Grilly

Nicolas Grilly — Thu, 04 Mar 2010 07:58:50 +0000

In my company, we were used to develop our forms using a home grown form generation framework. But what Ian mentioned many times in his blog happened. We were constantly trying to work around the limitations of our library to correctly handle side cases, constantly fixing bugs, and constantly wondering how to document a such complex library.

Then we have read “On form libraries”, the Ian’s post. It convinces us to ditch our form generation library. We replaced it by a more “low level” solution:

We code forms in standard XHTML, in Genshi templates.
We use Genshi macros to create and reuse complex widgets.
We use HTMLFormFiller, a Genshi feature, to automatically fill the form (this the Genshi version of htmlfill).
We validate inputs server side using FormEncode.
Forms are submitted in AJAX using jQuery. The server response is a bit of Javascript executed by the client. If the input is valid, the server returns something like “window.location = …”. If the input is invalid, the server returns something like “showErrors(dictProducedByFormEncodeEncodedInJSON)”. The Javascript function showErrors shows an error message (like “Please complete or correct highlighted fields”) and highlights invalid fields. Thanks to the AJAX form submission, we have eluded the problem of regenerating the form server side when a validation error occurs, which requires to redisplay data entered by the user and inject error messages in the form template.

Conclusion: We are very pleased by the solution Genshi + HTMLFormFiller + FormEncode + jQuery + AJAX submission. The code is easy to read and to maintain by a third party. It is highly flexible. And it is well documented and almost bug free.

By: Krish

Krish — Wed, 03 Mar 2010 17:33:13 +0000

I, myself burnt my finger with toscawidgets dynamic forms when I am developing a pylons application. I could have used simple html tags. There was no way to bend the form, the way I like.

But I learnt the hard lesson when I want to modify the form contents. I have spent more time to hack and learn the spec.

Simple hand written html form is easy to maintain and easy to read at the end of the day if we have isolated html and css/styles.

By: Ian Bicking

Ian Bicking — Tue, 02 Mar 2010 17:16:38 +0000

Honestly, to really figure this out I’d want to sit down with maybe a dozen fully thought out examples from realistic situations, both simple and complex, and start to brainstorm ways to solve that whole set — satisfying the complex ones without sacrificing the simple ones. And without shying away from ad hoc code in the hard situations. Combine that with a few design principles, and I’d be curious what would come out…

No module-level declarations (that can’t be trivially moved into a function). Classes can technically be moved into a function… but somehow it seems quite wrong. Mostly because of the structure of declarative classes, they tend to make data into code (e.g., strings become variable names).
Has to take into account agile HTML design.
Javascript is on the table. Ideally jQuery, definitely not Dojo or GWT or any frameworky Javascript. I carry my framework bigotry with me when I visit other lands.
Pushback on requirements is acceptable. Pushback should always be acceptable, it just has to be justified.

With further thought, I think another tension I feel is that I like things to be what they are. For instance, I hate stuff that compiles into Javascript. Similarly HTML is the canonical form of HTML forms.

By: Istvan Albert

Istvan Albert — Tue, 02 Mar 2010 15:56:38 +0000

In my opinion your code’s apparent simplicity comes primarily from the simplicity of the problem that needed to be solved – and not from the methodology itself.

Jacob Kaplan Mosses example has a logical layout with a self documenting nature and an internal structure that another programmer can pick up on and work with.

Your code on the other hand can only be modified once someone has read an understood every line of code.

By: Martijn Faassen

Martijn Faassen — Tue, 02 Mar 2010 00:35:43 +0000

I totally agree with those gripes. Especially of course the complexity and hackability one – form frameworks tend to be very magic. I think that’s Ian’s point: there are so many edge cases and special features that form frameworks can’t handle them all or is buggy and you end up with more complexity than hand-rolling something instead.

I just wanted to move away from framework hating to actual considerations about what makes a form library/framework/architecture work better.