TurboGears 1 had Catwalk.  This provided a crud-based interface for your models.  It was directly tied to SQLObject, which meant when you moved on to SQLAlchemy, you couldn’t take it with you.  Since TG2 decided to only support SA (SQLALchemy) out of the box, we lost our only Admin-like competitor, and this really hurt the project.  Although many people didn’t use Catwalk beyond trying it out, many hung on to the fact that they _needed_ this kind of interface when making the decision about what framework to use.  Since other frameworks have this sort of interface, TG really lost out.

When I first set out to build an Admin interface for TG, I didn’t really think about what kind of impact it could have on a developer’s ability to code.  I simply wanted to provide the developer with a way to get at their database tables.  DBSprockets was the result.  It _sort of_ worked, but the problem was that it was table-based, and therefore lacked the ability to leverage the developer provided mapping that every TG project utilizing the SA ORM (Object Relational Mapper) contains.  This was mildly successful, and while my first attempt to make it easier to use outside of an admin interface (something called “primitives” ) was less than successful, it became clear to me that the auto-generated forms could be useful in their own right.

Spurred on by an unsuccessful attempt to use the peak-rules based form generator called Rum, I was determined to make it easier to auto-generate forms, and make something easy enough for the masses to grok.  Sprox was born.  Sprox allowed me to drop much of the cruft that DBSprockets contained, and allowed me to provide a much easier way to define what I wanted customized in a form in a declarative manner.  I was inspired by SA’s declarative extension, so much of the framework is modeled after that design style.

The one design methodology I kept from DBSprockets was the database abstraction layer.  I still have the idea that we should be able to support our SQLObject users, and we also need to be able to support the plethora of persistence solutions that have yet to be discovered or created.  This abstraction layer probably seems unnecessary, considering that SA itself is an abstraction layer, but this layer allows you to provide access to numerous ways of interacting with a persistence mechanism.  In this way, Sprox is able to talk to both MySQL, and MongoDB.  Preliminary support for this has begun in the Sprox 0.7 fork, to be released in early 2010.

Sprox is really the bricks in the house that is the TurboGears Admin.  After some trials with what I called Catwalk2, I decided that it would be easy enough to provide a framework for developers to use Sprox, as well as develop a configurable admin.  In 2.0 the auto-configured TG Admin was called Catwalk2, in 2.1 we have dropped Catwalk altogether and just provided TGAdmin configured, which makes it easier to follow documentation about how to change the configuration.

The Turbogears Admin System is made up of 4 main components.  These connect together to provide a system that you can customize at every layer

Sprox – We already have discussed this, it provides a way to generate forms from DB Schema.

CrudRestController – This provides a restful interface to each one of the models in your Application’s persistence layer.  It utilizes TG’s RestController to enable RESTful urls to work with your models.

AdminConfig – Allows the developer to override settings in the admin to customize those things which may be different from what Sprox provides as a default.  It also allows you to override the default behavior of CrudRestController, in the event that you need to modify the way your models interact with the database.

AdminController – Combines the above 3 things to provide a set of controllers for manipulating your models.

One of the benefits of using a configuration-based Admin is that this allows the developer to override functionality at any layer. The developer is not confined to providing an all or nothing solution.  With the AdminConfig, you can limit the models, swap out forms with Sprox autogenerated ones or provide your own customized ToscaWidgets forms.  The developer may choose to  override one method of the crud, or provide a different set of authorization predicates.  Templates are overridable, so you are not stuck with the default look-and feel.  The admin supports both Mako and Genshi quickstarts, which means that your project’s master template is supported regardless of which template language you have decided to use (Mako is much faster).  You are also not limited by the number of admins you choose to create within your TG application.  This would allow you to create an admin-level admin, or simple crud based web application for user-level users in the same application.

The most compelling thing about the Admin for me is the fact that each layer can be used independently.  Sometimes you want to provide your users with _just_ a crud interface on one model.  It is simple enough to pull out the CrudRestController and use it as a stand-alone in your project.  Often times I will want to provide just one form that might have many fields in it.  I may just use sprox by itself for that.  The admin system allows you to customize at the layer you need to modify without getting in your way.

Here is the use-case I thought about when I designed the Admin.  You meet with a customer who already has a database.   You connect to their database, extract the necessary schema information.  You then take this schema information, and generate a TG application that allows you to see their database.  The customer then provides feedback about what their interface should look like for each model while you peruse their data in the Admin.  Some things you fix on the fly, and can show the customer how it looks on the spot.  Other things you take notes on, and work on later.  Perhaps they have a complex validation scheme, or require form that has a drastically different look than: fieldname [value].

Later you return to the customer after creating CRCs for each model requested.  Something is wrong though, the customer needs the database interaction to work differently in the back end.  You modify the controller methods of your CRCs to do so.   The customer is pleased with the quick turn around time, you are happy because you didn’t spend your week writing the same crud interface over and over and over.

Use case or not, I have been able to successfully accomplish the goals of my clients in a shorter time frame by modifying only those things that are different from the intelligent set of defaults that Sprox and CRC provide. Having crud, and customizable forms and tables often gets me 90% of the way there, and the last 10% is where I want to work anyway.  The fact that Sprox provides infinitely scrolling tables is nice too.

This entry was posted on Tuesday, October 20th, 2009 at 11:54 am and is filed under DBSprockets, Python, Turbogears, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.