Rails and Django - Other Features (part 11/15)

The following features are also important considerations when evaluating a web development framework. However I have decided not to put a rating on them, either because there is not much at issue, or because there isn't much the framework really does, the features are premature, or its not a high priority for my projects. Your mileage may vary.

RESTful

RESTful is a clever approach to writing web interaction, using the actions built into the HTTP protocol, like GET and POST, as verbs on your application objects. For example a HTTP request (URL string) to display a product page is requesting a GET; and an HTTP request to save an order form is requesting a POST of that order. A single URL can be used for both of these, such as http://www.mysite.com/product/123 -- when its a GET you're getting the product Id 123, the same URL as a POST might be updating that product record.

• Wikipedia on REST: http://en.wikipedia.org/wiki/REST
  
• A Rails blogger comments on REST

There is nothing in either framework preventing RESTful programming, it's a methodology. However, Rails has added some library functions to facilitate coding, a scaffold generator for making skeletal RESTful controllers, and has begun to evangelize REST as part of the Rails development culture.

Conclusion: A nod to Rails for leading in that direction.

RSS/Atom/XML

RSS and Atom feeds are XML formatted data. Both frameworks are fully capable of supporting data requests in these formats. Python and Ruby include full support for XML structured documents.

Conclusion: It's needed, it's there.

Internationalization and Localization

Internationalization (enabling software for many languages, abbreviated "L18N") and Localization (implementing a specific language translation, abbreviated "L10N"), includes Unicode support, and string replacement.

Both Rails and Django support it, in different ways. Rails via a plug in; given the international popularity of the framework, no doubt it works. Django has native support; its admin app, for example, has already been translated into over a dozen languages.

Conclusion: This is not a high priority for me today, but no doubt it will be at some point, and I'm confident others are making it work.

Caching

Caching is the temporary storage of chunks of data so it can be retrieved much faster than the processing time needed to generate the data in the first place. Browsers have cache to retain pages and images that have been downloaded so you don't have to download them again.

On the server side, a framework cache will relieve the server from having the regenerate the same page chunks over and over again with repeated requests. This is most important and noticeable on high traffic sites.

Caching whole static pages (pages that don't change very often) is easy to automate. You still should be allowed to control when a page expires, however, to force a regeneration. On very dynamic pages, you can simply disable caching (you'd expect your shopping cart, for example, to be fresh each time it's reloaded).

Complexity comes when you try to optimize performance by caching static parts of a page and not caching the dynamic parts. You should be able to cache some page fragment and leave other fragments uncached.

Caching subsystems may also give you the option of caching on the server disk, in the database, or on a separate high performance memcache servers.

All this is fairly standard IT management, and both frameworks support caching.

Django adds support for caching binary objects as well. I don't know if anyone would bother to use it though. That level of fine tuning might be needed if you're approaching the traffic volumes of a Google or Amazon, but then you probably shouldn't be using either of these frameworks anyway.

Conclusion: HTML cache is necessary and supported in both.

Security

Security can refer to many things.

Whenever you have users submitting content, you are vulnerable to abuse. A common hack, cross-site scripting, is to try and insert tags like Javascript commands in content areas that allow HTML. A common solution is to strip any tags from user input, either before you save it to the database and/or when you display it. When you do need to allow tags in the content, be careful and selective with who input that text. This comes down to good programming practice, and is not very dependent on your framework itself.

Similarly, SQL injection is when a user inputs content that looks like SQL statement so when it's passed to the database trips up the database request.

Both the Django and Rails documentation offer advice on how to program properly to avoid these traps.

Security can also refer to permissions for accessing specific areas of the site, specific content, or specific operations on the content. For example, Visitors may view articles, but only Editors may submit them. This comes down to administration of users/groups and permissions. As mentioned earlier, neither framework offers very significant support for access controls, but do provide tools so you can build your own to your specifications.

Related to users, security also refers to authenticating users when the log in and/or hijacking a user's session. Again, Django has a rudimentary admin with basic authentication. Rails has is via separate plugins. Both support encrypted passwords and such. The rest is still up to you.

Hackers can try and break your site by entering invalid data in the URL, and if you don't trap the exception may result in an error page listing sensitive information and expose other nefarious ways into your system. Again, this is more about good programming practice and testing as you should be careful to trap exceptions created by invalid parameters to your functions.

Conclusion: At this time, it seems the best these frameworks can offer is some rudimentary security and a lot of documentation on best practices.