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:

http://kill.devc.at/system/files/angry-cat-small.jpg 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
  = http://my.app.com/index
return  "Hello App!"

http://kill.devc.at/system/files/angry-cat-small.jpg 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 http://my.app.com/index. 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?"
http://kill.devc.at/system/files/angry-cat-small.jpg So let's query a database, shall we?

He flipped to the next page:

myapp isa web:application = http://my.app.com/

employees isa web:page
  = myapp:all-employees
return
  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?"
http://kill.devc.at/system/files/angry-cat-small.jpg 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.
http://kill.devc.at/system/files/angry-cat-small.jpg 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
return
   <root>{
      for $m in // employee
      where $m <-> manages
      return
        <manager>{$m / name}</manager>
   }</root>

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?"
http://kill.devc.at/system/files/angry-cat-small.jpg 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?"
http://kill.devc.at/system/files/angry-cat-small.jpg 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
return
  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:"

http://my.app.com/employee?name=Jon%20Lord

"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.

http://kill.devc.at/system/files/angry-cat-small.jpg 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."
http://kill.devc.at/system/files/angry-cat-small.jpg Yes, so what?
http://kill.devc.at/system/files/angry-cat-small.jpg 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

Temple?

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

Sweet

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