Davblog

In which someone you've never heard of writes about things you have no interest in

Posts Tagged ‘rails’

Templating Systems

I’ve been thinking about templating systems a lot recently. By templating systems I mean technologies that allow you to mix some data with some fixed text to produce some kind of output. One obvious use is in creating dynamic web pages where, for example, you would create a row in a table for each item that you pulled out of a database table. Templating systems form the view component (the ‘V’ in ‘MVC’) of many web frameworks.

There seem to be two schools of thought on templates. Some people think that the best language to use for templates is the same language that you use for the rest of the system. This is the approach taken by Ruby on Rails, where the you templates will contain a lot of Ruby code. Other people, and I’m one of them, think that it’s better if your templating language is completely different from the rest of the system. We believe that presentation logic is (or, at least, should be) much simpler than the rest of your code and that using a deliberately simplified language forces you to separate your business logic from your presentation logic and that leads to cleaner systems. Also, it’s often the case that templates are written by a different set of people than the rest of the system and you shouldn’t really require the template developers to be experts in the programming language that is used for the rest of the system.

It seems that this separate language approach is starting to catch on. Perl has the Template Toolkit which has its own presentation language. PHP now has a separate templating language called Smarty. Django (a web framework written in Python) has uses a similar approach. And even Ruby on Rails has just gained a new separate templating language called Liquid.

But that’s not all. As I noted when I wrote about the recent web frameworks night, all of these templating languages look very similar. And that’s what got me thinking.

Consider the (common) case where the templates are written by a different team of people to the backend code. We’ve already established that this team shouldn’t need to know whatever programming language the rest of the system is written in. If we assume that this is a web-based system then those people will already be experts in HTML, XHTML, CSS and JavaScript. There’s really no reason for them to be experts in Perl, Python or Ruby as well.

But the way things are currently they might not need to know Perl, Python or Ruby, but they do need to know whatever templating system is being used. So the choice of backend language is effecting what the frontend developers are using. And that seems wrong to me. Given that many of the templating languages seem to be converging on a similar syntax, isn’t it worth giving them that extra push so they just become the same language? That way, frontend developers can just become experts in “templating” and it doesn’t matter to them what language is being used at the backend.

We don’t expect frontend developers to use a different type of HTML because the backend is written in a different language. Surely it’s a bit weird to expect them to use a different templating language.

Oh, I realise there would be a lot of work to do. Working out a “best of breed” syntax across all the existing templating systems would be difficult. And then you need to work out how each individual programming language would interface with the templates. But isn’t it something at least worth investigating?

Web Frameworks Night – Report

So last night was the Web Frameworks NIght. A great time had by all. Many thanks to the organisers.

We had talks on three frameworks – Catalyst, Django and Ruby on Rails. My overwhelming impression was how similar all three frameworks are. There really seems to be little to differentiate them.

As always the Perl community shot itself in the foot a bit. I know that Catalyst is a great framework and I know that Matt Trout knows a lot about Catalyst. Unfortunately he doesn’t know enough about how to sell Catalyst in a presentation. As a result his talk had a lot of slides full of code which would have been almost inpenetrable to anyone who didn’t already know Perl. He also failed to give any demos of Catalyst in action. But I thought his biggest mistake was to overlook the one area where Catalyst scores heavily over the other frameworks – the ORM tools that Catalyst are much more powerful than the ones used by the other frameworks. For example, with Class::DBI::Loader you can automatically pull the relationships between your tables out of the database.

Django looked interesting. In particular the default admin screens that it creates had everyone in the audience going “oooh”. Django templates use a language that looks a lot like the Template Toolkit, but apparently they are based on the PHP templating system Smarty – so it must have been them that borrrowed the ideas from TT.

Then there was Rails. I don’t really think anyone in the audience was there to find out about Rails. It’s been getting quite enough publicity recently so I think every has at least a basic knowledge of how it worked. I think most people were there for a first look at the BBC programme catalogue that Matt Biddulph is building. And it didn’t disappoint. It looked lovely. I foresee a few wasted days when that is released next year. Oh, and it was nice to hear that some Rails programmers are moving away from the idea of using embedded Ruby as their templating language. A new templating language called Liquid has just been released. This is based on the Django templating language (which is based on Smarty, which is based on TT).

So, to summarise.

  • All MVC web frameworks look very similar
  • Catalyst has the best ORM capabilities
  • Django has the best default admin templates
  • Rails has the mindshare
  • They are all starting to use templates that look like the Template Toolkit

Update: blech points out that I missed out Catalyst’s big advantage. By building on Perl’s existing DBI framework, it already comes with connectivity to far more database systems than any of the other frameworks.

Update: Here are links to all the presentation slides:

Java Programmers Embrace Ruby

Bruce Tate’s book Beyond Java has been published and there’s quite a lot of publicity for it appearing on the web. For example this article by Chris Adamson on the OnJava site. In the article Adamson interviews a number of well-known Java programmers about the future of Java.

The replies seem pretty unanimous that Java’s dominance is nearing it’s end. They seem to think that Java has become too top-heavy and that it’s becoming too complex to be usable. Oh, they all agree that it’ll still be around for some time (much as COBOL was for many years) but it’s surprising how many of them are looking closely at Ruby on Rails.

As someone who has never been a big fan of Java and who has always preferred the freedom of “dynamic languages”, it’s interesting to see so many respected Java programmers coming round to my way of thinking. The advantages of Ruby that they talk about are exactly the advantages that you’d get from any dynamic language. Sure, we get the same old tired nonsense about how Perl encourages untidy code but all in all it’s all starting to look like a good time to be a programmer specialising in dynamic languages.

Now, if only we can start marketing Catalyst as well as the Ruby on Rails people market their framework.

London Web Frameworks Night (Update)

The London Web Frameworks night has proved to be very popular. So popular, in fact, that the organisers have had to change venue. It will now take place in the New Cavendish Street campus of Westminster University. See Dean’s post for more details.

This means that signup has been re-opened for the time being. But places are still going fast, so sign up now if you’re interested.

Should be a good night. Say hello if you’re there.

London Web Frameworks Night

November is shaping up to be an interesting month in London. Not only is there the London Perl Workshop that I mentioned yesterday, but Dean Wilson has organised a London Web Frameworks Night on November 17th. Three experts will be discussing the major MVC frameworks for Perl (Catalyst), Python (Django) and Ruby (Rails).

And it’s at Morgan Stanley too, which is a very cool place to hold a meeting. More details as soon as I get them.

Update: Sign up here.

ActiveRecord Does It Wrong

I’m listening to the keynotes on the final day of EuroOSCON and David Heinemeier Hansson is talking about the secrets of Ruby on Rails. He talks about how they promote “convention over configuration” and how that means that you don’t have to describe the same object attribute multiple times. This is a great idea, but one of the key parts of Rails (ActiveRecord, the part that talks to your database) forces developers to break this rule. When defining objects in ActiveRecord you need to describe all of the relationships that the object has with other objects (tables) in the database. This is repeating information that should be stored in the database. All databases (well, all databases that you should consider for serious development) allow you to define these relationships in the database metadata. Why doesn’t ActiveRecord pull back this information from there? I suspect that it might be because most Rails users will be using MySQL as their database. And MySQL doesn’t exactly make it easy to extract this data.

I’ve written about this before. This post is really just here as a pointer so that new readers can find my previous articles.

Databases and Metadata

Following on from my previous post let’s take a closer look at the kinds of metadata that you might put into a database and how an Object-Relational Mapping layer (like Class::DBI, ActiveRecord or Hibernate) might make use of it. We’ll start with the most obvious stuff and work our way down to less common features.

List of Tables
Any database system will be able to give you a list of the tables contained in a given database. This means that given a database connection, an ORM will know which classes it needs to model.

List of Columns in a Table
Given the name of a table, the database will be able to give you a list of the columns contained in that table. The ORM can use this data to know the names of the attributes that it needs to create for each class.

Data Types of Columns
Usually, the same database query that gives you a list of the column names for a table will also tell you the data types for those columns. The ORM can use that information to carry out basic validation on the values given to the corresponding attributes.

Relationships
A database isn’t much use unless there are relationships between the tables. These relationships are modelled as primary keys and foreign keys. The ORM can query this information and use it to infer relationships between the classes that it is creating. Some databases also use these relationships to enforce the integrity of the data and will return an error if you try to transform the data in a way that breaks that integrity (for example, if you try to add a record for an order that references a customer which doesn’t already exist). The ORM should look for these errors and handle them appropriately.

Constraints
Many databases allow you to define constraints on the data that is stored in a column. For example a column containing a percentage might be constrained to only accept numb ers between 0 and 100. Or a date column might only accept dates after a given date. Or a string column might only accept a certain set of strings. This basically further constrains the datatypes that we saw above and the ORM should be able to use them in the same way.

Triggers
A trigger is a piece of procedural code that is run whenever a certain event occurs in the database. Most commonly they are run when a row of data in a table is inserted, updated or deleted. The trigger is given the data values before and after the update and can use these values to run further validation on the update or even to run further updates. In some cases the trigger can prevent the update from taking place. This code shouldn’t effect what the ORM does, but it needs to be aware of the potential return values and handle them appropriately, for example, realising when an update hasn’t taken place.

Stored Procedures
A stored procedure is a piece of procedural code which can be run at any time by any user connected to the database. Again, this should be largely outside of the jurisdiction of the ORM as stored procedures are usually not associated with a particular table (i.e. class) but it would be good if it provided a simple way to call stored procedures and retrieve any results.

Now, I don’t believe that any ORM has all of these features yet, but I think it’s a reasonable set of targets to aim at. you should be able to point your ORM at a database and a complete set of classes back. Having to define the relationships between the tables using a text file or in hand-crafted class definitions (as you do with ActiveRecord) is just a waste of time. We should expect powerful tools. And if we don’t get them, then we should help to improve the ones we have.

Which means, I suppose, that I should be helping to ensure that Class::DBI has all of those features.