RTML - The templating language created by pg

    Isn't a fundamental problem that form is function?
    With that I mean that in the end the form of the UI
    is part of it's function. So are other parts, e.g.
    "content" is part of the UI's function as well.

However, I think there is an important contrast between logic and presentation from the perspective of the system. Generally, we don't care too much what a user does with their user interface. If it crashes or displays something weird this is unpleasant and undesirable but unlikely to be more significant than that. A layer back from that, what happens in the application itself is certainly important but not critical - if it approves a transaction at a wildly wrong price then this is certainly a bad thing, but in an enterprise application you can often reverse or at least cover position on this before the close of business. Then a layer back you have a datastore - and if stuff is in here and wrong it's very unsettling because that's the source of evidence about the nature of the world your product lives in.

At the moment, we (computing world) commonly protect datastores against certain sorts of danger by using a relational database with typing and primary/foreign-key constraints. This is all very nice, but only offers basic protections on a datatype layer - it is ignorant of your business circumstances.

The common evolution to achieve greater business integrity is to hide all communication with the database behind stored procedures. I think the reason for that is to do with tools and skills - it's easy for banks to hire Oracle guys who can do this work.

One failure of this is that it's not stateful beyond the state you get with a database transaction, which for a distributed application needs to be short-term (ie: not span longer than a few ms if possible). Sometimes you might want to issue the user with a long-life token that they can use to recall a position later on. This is 'possible' using stored procedures and database transactions, but highly impractical [1].

A second failure is that you don't have a nice mechanism for stopping the sort of bad transactions I talked about before without code and interface logic getting all confused with one another. Those problems occur often because programmers will hook interface into the system in ways that are subtlely wrong. I see this as being a room for improvement.

A third problem is that you end up with a range of inconsistent RPC interfaces glue into the side of the business logic layer. Once these interfaces are in it becomes awkward to reform the business logic because everything you do has RPC consideration. My background is in foreign exchange trading APIs and I've seen this pattern repeatedly here. But it's equally valid in a situation I faced when I was consulting where a third party developer was writing a web frontend to my franchise management system. [2]

What you really need is to be able to defend not just the datastore, but the business logic of your application space behind an abstraction layer that is comparable to that which we get on the datastore layer with the patterns of tables, operations and short-lived transactions. The goals of this pattern include (1) ensuring that nothing bad gets in; (2) support for concurrent long-life transactions things can be done in certain ordered steps; (3) supporting a programming team role for someone who is focussed on the business logic and has no interface considerations beyond the logic layer's facade patterns.

The pattern I'm talking about is actually somewhat similar to a text adventure, where the application presents you with a common interface, and track your state as you proceed through it using a limited syntax.

After implementing the first version of this pattern I discovered a really neat side-effect: it becomes trivial to write a dumb interface layer that automatically creates blunt user interfaces from the logic presentation that are suitable to present to users. [3] Shortly after that I wrote a simple syntax that allowed me to define unit tests before writing any application on it.

I've finally managed to develop most of what I'm talking about above after three years and at least four rewrites. The most recent version is in python and actually took only a day to implement from nothing. Building apps on it is pretty straight forward - I built a simple expert system in it in twenty minutes the last time I played with it, and then automatically had multiple user interfaces to it (web html, command-line, WSDL, unit-test, etc). However, I'd like to improve the mechanisms used to easily bind user interfaces to the system before I start to invest energy in attracting a community and other programmers.

If you have any further thoughts about this or even whether my explanation makes sense I'd be interested to hear. Thanks.

--

[1] You can't just give them the id of a table and maintain validity, because when it came back in you'd then need to vet it to make sure it was one they should be dealing with). In my own attempts to build logic layer platforms I call this sort of token a 'reference'. The reference is mapped to an actual object (or table id or whatever) within something like a stateful session bean on the server side where integrity can be trusted.

[2] In much the same way that tools like Toad can inspect and allow you to interact with numerous relational databases of varying structure.

[3] In the early meetings they were fans of just writing directly into our database. No thanks - don't really want to be supporting the consequences of two systems created by different programming teams depending on the same database. However - an arrangement like that with stored procedures is common in the enterprise. This has huge consequences for interlocking the design of the applications that interact with the datastore, and creates larger depenence on key staff.