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:
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?"
So let's query a database, shall we?
He flipped to the next page:
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?"
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:
= 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?"
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:
= 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:"
"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?
- "Cannot you remember how the TM people reacted when I had proposed to interpret functions, predicates and ontologies as topics? In that ISO meeting the reaction ranged from fear, anger to open aggression. How do you think will the ultra-conservatives react to such outrageous ideas?"
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.
Look what I have done with my language TempleScript! 
Temple?
This looks very interesting. I'm definitely looking forward to the conference paper. An implementation would be nice, too.
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 :)
Post new comment