Rails and Django - Templates, Forms (part 8/15)
Templates
Obviously both Rails and Django support display templates, as this is a cornerstone of the MVC architecture separating content from presentation. Templates define the layout and formatting of data, for example, into HTML that is sent back to the user's browser in an HTTP response.
In general, templates are intended to be created (or at least edited) by non-programmer designers, an important consideration on team projects. Some debate has ensured regarding just how much programming features should even be permitted in a templating language.
Rails templates let you use the full power of the Ruby language, but you are "strongly encouraged" to use discretion and not put business logic into your templates (move it into the Controllers instead).
Django templates have their own little language that is intentionally limited to simple conditional and iteration control structures, and oriented toward non-programmers (i.e. designers).
Both frameworks permit page layout templates for sharing layouts among views, and specific templates for individual content. In Rails you use "layouts" (parent page), "partials" (included sub-page), and "collections" (an iterated partial). You can write "helper" functions to extend your tags.
Similarly in Django a template can "extend" a parent template (comparable to Rails' layouts but can be multi-level), "inclusions" of sub-pages, and write custom filters and custom tags. In both frameworks you can pass variables to the various template components.
Both frameworks permit you to replace the default templating system with third party alternatives. If you're using Rails but prefer Django's templating language for your designers, for example, someone has written a plugin, named "Liquid" which does just that.
Opinion
It's nice to have the full power of Ruby inside the templates. But I see the point about it being dangerous. And if you're really doing that, the logic should be moved into the controller. Otherwise they both have very good templating features. So I call it even, 3-3.
| Templates | Rails | Django |
| Language | Ruby | Django-template language |
| Parent layouts | "layouts" | "extends" directive (bottom up) |
| Include templates | "partials" | inclusion tags |
| Extensions | "helpers" | custom filters and tags |
| Can use alternatives? | yes | yes |
| MY RATING: (1=worst, 5=best) | 3 | 3 |
Forms
Basically the role of a framework with regard to forms includes
- Generate HTML <label> and <input> tags based on Model class attributes
- Produce those fields in an empty <form> for creating new objects
- Produce those fields in a <form> with values filled in for updating an existing object
- Validate values posted by the form based on the Model's validation rules
- Return to the form, with error messages if any fields do not validate
The logic and syntax may vary somewhat, but both Rails and Django have very good forms support.
Django is presently in the process of rewriting its forms classes to be more flexible. It is available for download from the repository.
Rails includes support for forms that populate multiple Models. Rails also introduces the notion of "form_helpers" that help you standardize the look, layout and behavior of difference forms across your website.
Conclusion: I'll rate forms in Rails and Django equally, 3-3. I can see that Rails' is powerful, and we'll give Django's newforms the benefit of the doubt.
| Forms | Rails | Django |
| MY RATING: (1=worst, 5=best) | 3 | 3 |
Rails and Django - Templates, Forms (part 8/15)
Posted by: Henrique on September 07, 2008 05:11 PM#