To continue my random ramblings on the programmable web let's get into the other side. Theming.
These days it is a common place to have a theme engine available in almost any respectable web application. It's the result of the spearation of concerns mantra and the desire to get designers and arty types off your back, give them the freedom to do almost anything they want, while not bothirng yourself (as a developr/admin) with too much unnessesary support requests. Theme engines and ideas how to build them are plenty. They differ a lot. But let's try and dissect what are they doing, or more likely what should they do.
Introducing x-expressions
Most themes are based around xhtml these days. And for a reason - it is an xml dialect, and it has very strict parsing rules. That makes it easier. The lips clique has discovered long ago that there is one to one mapping between xml and s-expressions, ergo you can treat them as such.
If you've read the previous writeup you'll get the trend. I don't thing I need to write examples here, do I? We can turn any XML into a program. Probably the default behaviour of that program will be to print itself. As JSP tags showed how, followed faithfully by various taglibs, you can construct your own namespaces, encoding code into xml. The microformats can be treated similarly.
Mixing it
So, we have - p-exp - encoding the request into a program fragment, x-exp encoding xml into a program fragment, we have our application's framework, a program itself. Putting them all together in order we get a very familiar picture. REPL - the omnipresent read-eval-print loop. It is present in practically all programming languages and systems, although might not be called that way.
Let's look at this in more detail. The core code, has a bunch of symbols (functions, constants, variables,...) in the application's environment. The suggested treatment, will introduce antother group of symbols into the environment. All these will be availble for use or assembly before the request. These are our definitions.
If the request is treated as a program, this is the outside world's one-shot interaction with the definitions. It is a short program, so the slow down due to parsing, and interpretation should be negligible, compared to the benefits you get. Mainly freedom and flexibility.
More on the environments
shouts from the back row: "But that's insecure!"
Not nessesarily so.
What is in the environment is under the control of the server. You can't see what is not there, so you can't call what you can't see. If you have some strict programming discipline, differentiating what symbols, or what versions are availble in the environment for that user interaction, you are as secure as you can get. It is the equivalent of a jail.
The core code of your system can be, and probably is modular, precompiled one way or another. drupal is a very good example. The only request processing logic needed is to select which symbols should go into the environment, depending on user privilieges. This acts as a kind of security barrier.
The described ides, will probably lead to luggish code if implemented directly. For the x-expressions case the code can be precompiled and/or optimised. That is not that scary as it might look - look at smarty or php-template as examples of how to go some way towards this target.
The biggest difference I suggest is to promote the xml tags to first class language objects - they should be assignable, mutable, evaluating (including functions, where nessesary).
Essentially we will end up with a system of with one underlying evaluation engine, but multiple syntaxes. Each syntax specialised and taylored to the different specialised knowledge required by the end user. Designers - css+x(ht)ml, punters - urls, code monkeys - their own language + squeaks + caffeine, bots - s-expressions, x-expression, p-expressions
These are not unique ideas. For yeas KQL/KQML is used in the context of software agents. XML is used as encoding for xml-rpc, sopa, wsdl, uddx, add you favourite abbreviation here. Just mix everything together.
