AJAX and Yaws

Samuel Montgomery-Blinn <>
Fri Jan 20 23:38:30 CET 2006


On the one hand, it could be nice to write Erlang and have this exported 
to the user as JavaScript code. This is the approach that Uncommon Web 
uses, with Lisp. A colleague of mine uses the UCW platform 
(http://common-lisp.net/project/ucw/), and instead of expressing 
JavaScript, he can write:

...
:inline-javascript 
    (js:js
     (defun toggle-display (id)
       (let ((element (document.get-element-by-id id)))
	 (with-slots (display) (slot-value element 'style)
	   (setf display (if (= display "none")
			     "block"
			     "none")))
	 (let ((formname (+ id "-form"))
	       (textname (+ id "-text")))
	   (document[formname][textname].focus))))
...


As for me, I would express reservations on whether such a library is as 
useful as it might seem. It may save you (on its face) from having to 
write JavaScript functions, and being able to simply write Lisp, but in 
the end when you are debugging your functions, you will need the 
JavaScript skills anyway; only with such a library you would have to 
translate the resulting error back into the origin language (Lisp, 
Erlang, etc). In the PHP (and other similar languages) world there is a 
fairly nice library called SAJAX (http://www.modernmethod.com/sajax/). 
But again, the benefits of these libraries (perhaps rapid generation or 
prototype work, simplicity from the original author perspective) do 
generally have drawbacks in completeness. For example, to duplicate the 
logic of GMail keyboard keys, writing a javascript function in 
javascript was fairly straight-forward, but to do it in Erlang and have 
it translated into Javascript, hoping that the translation is as you 
intended it, and then debugging when perhaps the generated script is not 
correct... it seems it would be simpler to use the domain language 
(JavaScript) than Erlang. There are large libraries of Javascript code, 
some of them even useful; documentation for Javascript interaction with 
the HTML DOM is verbose and widespread. Do we want to document all of 
the DOM again, this time for Erlang->Javascript->DOM?

That said, perhaps documenting an Erlang library would be as simple as 
declaring the Javascript that would result. But then to understand the 
documentation, you would already need to know Javascript, in which case 
you might as well write the script in Javascript anyway; this also lets 
you keep non-inline javascript (e.g. "mylib.js") and design your 
Javascript to be modular and re-usable for others, including those poor 
souls not using Erlang/Yaws.

As an example of how I current use Yaws/AJAX:

(somewhere in an ehtml clause...):
  {td, [], {input, [{type,checkbox},{onClick,"tdxToggleItem(this);"}],[]}},

The JavaScript function is defined in a library that is included in the 
HTML head section:
    <script language="JavaScript" type="text/javascript" 
src="tdxlib.js"></script>

Inside the JS library:
function tdxToggleItem(src) {
    // ...
    // send update
    
tdxSimpleItemUpdate(src.parentNode.parentNode.id,'complete',(src.checked*1));
    // ...
}

Which eventually does the "AJAX" way of using an XMLHttpRequest object 
to communicate the action via queryvars to some other Yaws URI.

Being able to shortcut the whole process by saying, perhaps:
  {td, [], {input, [{type,checkbox},{onClick,{mylib:myfun(E) ...}],[]}},

That would be the interesting part, but one which would either require 
heavy configuration or native Yaws support for such a thing.

-Sam




More information about the erlang-questions mailing list