Feed on
Posts
Comments

Application UIs - automating the CRUD

Jul 14th, 2006 by Phil Dawes

Pretty much all the ‘work’ applications I’ve built in the last couple of years can be split into 2 parts:

1) CRUD: The database, and a UI for manipulating the data in it
2) LOGIC: The actual application functionality. (i.e. the reason for the app to exist)

These days I’m finding that the amount of actual logic/functionality I put into each app is pretty small, and so part (1) becomes a correspondingly big piece of each application. This is especially true now that we’re getting used to gluing small applications together with HTTP rather than building big pieces. This appears to be a global trend - especially with web2.0 mashup buzz and lots of apps that focus on doing a single thing well.

The interesting thing is that the CRUD part is usually pretty generic. One UI fronting a bunch of crud operations on a database isn’t that much different to another. Thus it makes sense to factor this out and implement the two parts as seperate physical deployments that share the same database.

Breaking the two parts out means you can choose different technologies for each one. This works really well with web applications because you can stitch the seperate deployments together into a cohesive looking site using links and a shared CSS. In my most recent app I used Django for the CRUD UI, and implemented the application logic (which didn’t need much of a UI - it was an opaque service) using tomcat. In fact the actual app functionality was implemented as a single servlet.

So why Django for the CRUD UI? Well mainly because it dynamically creates a pretty sophisticated admin UI for you for free.

Aside: A few years ago I wrote a small webapp that dynamically generated a UI to edit relational database tables. Sortof similar to phpmyadmin, but it used FK information to work out relationships between entities and gave you hyperlinks and drop-down lists. This was fine, except that RDBs don’t provide particularly intuitive mechanisms for dealing with complex relationships (ownership, many-many etc..), so you can only get so far using one.

Django goes further than this by moving the model definition from the database into a configuration file (well, actually a python source file but you can treat it as a config file). This allows you to augument the basic entities with relationship metadata. Django can then autogenerate tables from the config (or you can wire the model up to existing tables). However, the icing on the cake is that the config also enables you to give django UI hints for how the dynamically-generated admin GUI should look. I think this is a really powerful idea and gives Django a edge over Rails when building simple CRUD apps.

So this leads me to think that there’s a killer business application here just waiting to be written: Decent dynamic RDB CRUD GUIs without code.

(yes, I know dabbledb does something like this, but I think relational DBs are key here. Both because they’re well understood by ‘business’ developers and because they’re an excellent technology for integrating data with the ‘functionality’ bit of an application.)

Here’s some basic ideas:

- UI for creating tables and metadata. Metadata stored in the RDB with the tables.
- Auto generated sophisticated admin gui, a-la Django.
- Security model that enables access control at a data level.
(e.g. think unix file permissioning: if I add a row, only people in appropriate group can edit it)

It might make sense to actually implement this with django.

(N.B. I’m not intending to actually write this app - I’ve got my spare-time hands full with large-scale data aggregation. Hopefully somebody else will do it. LazyWeb?)

Posted in General, Semantic Web, Python, Django, workfriendly | Comments

Viewing 7 Comments

    • ^
    • v
    Phil I have been working on something like this on and off for sometime. I already have a system for wrapping and extending existing databases in a schematized way called Base4... which is very similar to what MS promised with WinFS. Base4 allows you to register schemas at runtime.

    The key then is a gui to use this rich and powerful foundation, I have been playing around with a schema designer (www.base4.net/blog.aspx?ID=11) which I plan on extending in an application called work the list (www.base4.net/blog.aspx?ID=6).In which people can create views (or lists) over the relational data exposed by Base4. These views will in time be read/write. They key to the power of this is that Base4 can wrap multiple databases and make them look like one,by using Schema based declarative integration.

    I think this is quite similar to what you are talking about. Interested in your thoughts

    Alex
    • ^
    • v
    Hi Alex,

    I watched the demo (which I think cropped a bit - it finished just as you were getting to the wrapped fogbugz database). The schema metadata is pretty much what I was thinking of, although a rich GUI that can be given to users is the big win from the perspective of the post. I'd be interested to see what you can construct from the metadata in this regard.

    (Unfortunately I didn't actually try the software because I don't run windows, but I'm definitely interested in the approach!)
    • ^
    • v
    Automatically-generated or fully dynamic UIs may be a good way of prototyping the functionality of an app. Only if the app is only ever used by techies for low transaction volumes then you might consider putting the UI into production.

    I have NEVER seen an auto-generated UI that you would want to give to actual users. Don't make the mistake of thinking that dabbledb does this - it is a meticulously hand-crafted UI for a specific set of functions. It is partially dynamic to reflect the configuration that users choose - this is a good thing.
    • ^
    • v
    Hi Dom,
    Only if the app is only ever used by techies for low transaction volumes then you might consider putting the UI into production.
    I can see what you're getting at, but I don't think I agree. I'm not saying that any application is a suitable candidate for a generic rdb mapped UI, but I'd say that the sweet spot is pretty big even with just a small amount of sophistication in the mapping.
    Assuming the web as the deployment platform, people are already used to using pretty basic (and generic) UI widgets and layouts for entering and manipulating data.

    Also, why low transaction volumes? - I'd argue that transactional volumes don't have much bearing on UI design - more on the actual data modelling and access patterns, which you'd be doing with an RDB anyway. (or have I mis-understood something?)
    • ^
    • v
    We will agree to differ on the size of the sweet spot.

    To answer your question, high transaction volumes (if they arise from human input) should have a fundamental bearing on UI design. In this case you are designing for productivity. The challenges differ depending on whether your users are rapid data-entry clerks or simply the millions of great unwashed who want to use your website and don't want to spend all day learning how to do so.

    In either case it is worth investing in an optimised UI and not making do with an auto-generated one.
    • ^
    • v
    Ah -ok. I was thinking of high transaction volumes from a server perspective rather than in terms of individual productivity.

    This is an interesting point; My day consists of using a small number of desktop UIs constantly (email, unix console, emacs, browser), and a whole load of other intranet web based UIs infrequently (low 10s of times a day)?
    How does this tally with others? Is there a trend to using more interfaces less frequently as the repetitive tasks get automated?

    (I should also mention that django does provide some ui hints aimed at productivity - e.g. you can nominate to inline child objects with their parents, display a variable number of empty ones for quicker entry etc.)
    • ^
    • v
    Hey Phil... I just posted some screenshots of the SchemaBrowser/Builder app that now allows you to create as well as browse schemas, it is now near completion. I think of this as a Developer or Analyst tool.

    As you can see it is a WebApp.

    Next step is the a List/ListBuilder application, which will also be a WebApp. I am starting on that now. This List/ListBuilder application will be targeted at end users rather than developers.

    I look at it like this: Developers or Analysts lay a framework of data down using the SchemaBrowser/Builder, which the end users can then use to create Lists to report on and edit that data.

    Anyway you might be interested.
close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus