Unfortunately when you ty to find a system that is pure in separating logic from presentation you run into a situation of needing to have a logic core with no user interface assumptions wrapped by an interface filter. Building a simple implementation of this is not too hard, but doing it in a way that gives you the sorts of flexibility that will allow you to build something your users are happy with is very complicated.
I have an idea that such a thing is possible and have been working on just such a project for several years, but it's non-trivial, and I don't know of anyone having achieved it so far.
There are lots of systems that claim to separate UI from logic but which are in fact innundated with assumptions about state transitions. At some level, every system I've seen assumes a binding between GUI and application logic, even if it's not as obvious as in this case.
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.
This would imply that there's no true dichtomy between logic and presentation as such, but rather different types of functionality. Just as there are very seldom any bulk-heads between different types of a whole's functionality in general, I think it would be impossible to truly separate logic and presentation. (Not that some separation cannot go a long way.)
In the end we cannot escape presentation at any stage of the design of a system. If not anything else we have an internal presentation for the internal representation of the external problem. This alone makes us design things assuming much about the form. Is there even such a thing as representation without presentation? With that I again mean that presentation is a fundamental and non-separable part of any thing we handle.
I'm sorry if this comes across as mumbling. I've troubles expressing these thoughts clearly. Guess I don't understand them well enough..
It was me that set it off on a theoretical track. Thanks for your interest - no mumbling in sight :)
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.
I agree on the issue of form and function being actually the same. And in this sense, I think that blatantly mixing markup and code is a kind of honesty.
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.
Putting a little bit of logic in markup is OK, and Yahoo store pages are a good example of when that is appropriate because Yahoo store merchants just want some customization logic not a full-blown web app.
Putting a lot of logic in markup gets messy fast hence the rise in popularity of MVC frameworks for web apps. Even ASP had to evolve from "code in front" to "code behind" support in ASP.NET.
2. Add isomorphic whitespace and linebreaks that can be easily converted into the original s-expressions. Users: "golly, that's neat!"