Post-Modern WebApp Development

Life is full of coincidences: First I followed with interest the Ontopia web dev tutorial, then I had my more-or-less regular "TM brain storming pizza lunch appointment" with Robert (Cerny), keeping my head spinning with ideas for days. And just earlier I was passing by CatBert's office.

He was lazily typing on his CatBook: Look what I have done with my language TempleScript!

Actually TempleScript was our idea, but CatBert had started to take ownership.

Eating Your Own CatFood

His screen showed:

index isa web:page
return  "Hello App!" This is a complete web application written in TempleScript!

I immediately understood how that was supposed to work: A topic index is instantiated, with the type clearly recognizable as web page. A TM-based web app environment would understand the concept web:page, would create a new web object (defaulting to text/html) at the URL The content shown would be Hello App!.

  • "Ok, I can see how you cleverly reinterpreted the subject locator as the place where the page should be hosted. But otherwise the rest is a bit trivial, not?" So let's query a database, shall we?

He flipped to the next page:

myapp isa web:application =

employees isa web:page
  = myapp:all-employees
  select $e / name, $e / salary
     from http://database/employees
     where $e isa employee
     order by $e / salary desc

Not only had he replaced the website address with a prefix, he had also used a TempleScript query to list all names and salaries of employees.

  • "So the query actually creates a table. How do you render this for the web client?" Welcome to the year 2010, Robert. Actually I have created a REST endpoint. If the client asks for text/html, the application server is supposed to create an HTML table. Modulo the usual layout wrapping. If the client asks for JSON, because you want to fetch it via AJAX and use a jQuery table plugin for rendering, this is also possible. Duh.

Admittedly, I was impressed. I could also see how this would work if the query returned XML:

managers isa web:page
  = myapp:only-managers
      for $m in // employee
      where $m <-> manages
        <manager>{$m / name}</manager>

Either the XML fragments are directly shipped to the web client, or the endpoint uses an XSLT sheet (or other means) to convert it.

  • "And how do you specify what XSLT to use?" Well, that's maybe a detail right now. But you would create a content pipeline. Or directly use Apache. Or, even better: We could leverage your Formula 3 pipelines.

He was right. Apache module chaining would work. But many web application infrastructures (such as mod_perl2) also allow to chain up handlers. I am sure Java allows that too.

  • "And how exactly do you handle GET requests with parameters?" Nothing unusual: The infrastructure will capture the parameters into variables, and you can use them inside the query as free variables:

employee isa web:page
  = myapp:employee
  for $e in ($id || $name \ name)
  where $e isa employee
  return $e / *

  • "So this endpoint would either expect an ID for the topic or I could also provide alternatively a name, like this:"

"Nice." I thought. Because all the low-level security related features (unescaping, ...) could be handled by the infrastructure. And since the variables are not text-replaced in the query, but rather are normal TempleScript variables, there is also no injection attack possible.

Ontopia Flashback

Now the Ontopia way of life emerged in a new light. While I had appreciated the tutorial, the control flow using taglibs appears insanely convoluted, meandering through the JSP, to the tolog taglib, into tolog. And to make matters much worse, tolog would have incoming and outgoing variables. The curse of improper binding regimes.

OTOH I am guilty myself having produced infrastructures such as these. My only excuse being that this had been in the early 2000's.

Reality Check

Time to give CatBert his daily dosis:

  • "So I hope you do not want to publish this?"

CatBert was surprised. Well, Robert, I actually had hoped that you would impleme...
  • "Forget it! The idea is compelling, more-or-less innovative, certainly elegant. And if you think that further, your approach would also allow to define semantic meshups easily." Yes, so what? Robert, aren't you a bit too negative about it?
  • "No.", I responded coldly.

CatBert was pissed. With two mouse clicks he deleted all use cases. He knows how to handle a mouse.

Still, I had memorized everything. Time to put the idea into another conference paper.

Posted In


This looks very interesting. I'm definitely looking forward to the conference paper. An implementation would be nice, too.

Lars Marius Garshol (not verified) | Wed, 02/03/2010 - 14:17


Robert: I am glad you enjoyed my tutorial.

I have to concur with Lars Marius; this looks very interesting! Only hope CatBert wont get the best of you :)

Trond Pettersen (not verified) | Wed, 02/03/2010 - 22:37