The Magically Appearing Admin
Web developers using an MVC framework produce their websites playing with their models, views and controllers. Then by adding a few lines of magic an admin system appears which allows users to add/edit/delete/view/search their models.
Streamlined framework – http://streamlinedframework.org/
- Admin magic/config – outside of the models
Auto-Admin – http://code.trebex.net/auto-admin
- Admin magic/config – inside the models
Limitations of Database types and Semantics
While we could have an admin that displayed all a models attributes as text inputs, it would be nice if it was a bit more intelligent. We need the magic admin to infer what type of form input should be used from database types.
If within our database (and hence in the model) we have a
partyDate -> Datetime
Then we would like the admin to display a date styled input.
We have a limited set of database types:
For very simple magic admins these database types are good enough.
But we find in more complex instances the database types are not expressive enough. Within our models we have an implicit idea about the meaning of the attributes (generally derived from our naming of variables) not just the type.
For example we may have the concept of IPAddress within our model. We have a clear idea of the semantic meaning of IPAddress and that it should be presented as a form input in a specific way. e.g.
The database type is just char(12), so the database types are not enough for our magic admin to build a more complex admin.
Django Approach – Explicit & High level
Within Django we explicitly define all our Model fields in Python. We can introduce high level concepts like model attributes of type ‘IPAddressField’ and not worry about the way this maps to the db (Django deals with the transformation between IPAddressField and the database types).
[viewcode] src=../projects/python/examples/model.py geshi=python [/viewcode]
Ruby on Rails Approach – Implicit & Low Level
In rails our models define relationships between themselves but we generally do not list all model fields explicitly. That’s one of the beauty’s of rails compared to heavy ORM layers.
[viewcode] src=../projects/ruby/examples/Post.rb geshi=ruby [/viewcode]
To quote the Rails Active Record API
“Adding, removing, and changing attributes and their type is done directly in the database”
Hence we cannot easily attach metadata to attributes which are only defined in the database. We can overcome this by listing these fields in the model and attaching some metadata to describe the semantic meaning of the fields (rather than using special types for the fields in the model, keeping ActiveRecord happy).
But does this remove the idea of having lean and simple models?
Django’s high level model provides a very natural way to attach semantic meaning to model attributes which the admin can use. Its also all located in a single place, the model.
Rail has lower level models embracing the database, and attaching semantic meaning requires us to add more detail to the model, which feels like its breaking the DRY principle. Since Ruby embraces the idea of the only place certain model attributes are defined is in the database it feels like having the atributes mentioned in the model as-well is duplication.
Streamlined’s attempt (which is defined in a separate file to the model):
[viewcode] src=../projects/ruby/examples/streamlined.rb geshi=ruby [/viewcode]
There are potentially other ways of handling Rails representation of semantic information:
Storing the semantics in the database.
Imply semantic meaning from naming of database columns (‘myZipCode’ should use zipcode input type in the admin).
Customize Migrations to map semantic types to db types.
Rails has the flexibility to mirror Django, so can we find a good way for Rails to represent semantic meaning for models?
Interesting Further Projects
SemanticAttributes – http://code.google.com/p/semanticattributes/
Semantic Web, meet Ruby on Rails – http://www.jroller.com/obie/entry/more_about_ontologies