lost password?

home
•  xaraya
•  rails +
•  django +
•  webdev
•  xamp
•  musings

rss
Tag this page
   

ยป Blogs that link here
last modified: Mar 26, 2007
(first posted: Mar 12, 2007)
(3657 Reads)
Permalink

Rails and Django - Templates, Forms (part 8/15)

A technical manager's guide to evaluating web development frameworks, with a detailed review of Ruby on Rails and the Django (Python) projects. (Start here: Whitepaper index)

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
LanguageRuby 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

 


There are no comments attached to this item.

Post a new comment

: This is not spam

Name :