On Wed, Jun 23, 2010 at 9:01 PM, Alberto G. Corona <agocorona@gmail.com> wrote:

I forgot to send this to the list. This answers also some questions about the idea of server page control. I don´t think in to eliminate the option of client code, not at all. but server control is neccesary to ease interactions that MUST use data in the server.

In fact, as I suggest here, pottentially, HJScript can be extended to make it run in the server or in the client depending on the requirements, just modifying (i guess) the underlying monad, because it has many of the common functionalities needed.

Hi michael,
More or less to solve these concrete problems is a requirement. I think neither using comunications using algebraic data types, nor JSON neither HTML downloading of pierces. My idea is just to send javascript sentences from server to client, and then evaluate ( with javascript "eval") them in the client.

Details below:

2010/6/22 Michael Snoyman <michael@snoyman.com>

I think it would be useful if we spoke in more concrete terms: in particular, let's figure out some real world problems we want to solve, instead of designing the perfect technology. I'll start with some simple problems, feel free to add some of your own:

1) Form validation. Here's an example from a project I'm working on now: disable field B if field A has one of a list of values. We clearly need to ensure server-side that field B has no value set if the conditions for A are fulfilled, but we'd like to "gray out" the field client side.

because I have a copy of the HTML tree in the server( the way to maintain synchronization trough event forwarding to the server is not described here) I can check te value of the field A. If A meets the condition I just send to the browser the HTML DOM sentence

"form.B.style.active=Disabled"

(This is javascript pseudocode the real sentence look similar, but I don´t care now to check the documentation and look for the details)

in the browser the execution of

eval("form.B.style.active=Disabled" )

will disable the field.

If we develop a XML DOM library that generate javascript strings, then the haskell code in the server would map 1:1 with the javascript code.For the javascript developer will be muchi like developing javascript in the client. In fact the code would share ,much ideas and code with HJScript because HJScript does also generate javascript strings. I think that we can extend HJSCript to make it run either in the server or the client, depending on the choices. HJScript uses HTML DOM.

This case does a lot less sense if the control code does not make use of data in the server. For example, if the list of values of a combo box depends on the choice or values in another field in the form.

I understand the motivation here, but my biggest concern with this type of approach is that it seems very unRESTful. I'm not a REST idealogue, but planning to design a complex system that attempts to keep two identical copies of browser state over a stateless protocol just doesn't seem possible. I'm also concerned about Jeremy's comments regarding bandwidth usage and latency.

The approach I would take is to accept the fact that we're going to have to write code twice. But instead of writing a full-blown Haskell application, and then converting all of that code to Javascript, let's build small components that encapsulate the same functionality in Haskell and Javascript (the idea behind widgets). If we do it properly, we can easily combine these components together, and produce applications where the Javascript mirrors the Haskell properly, assuming the individual components are written correctly.

2) Ajax loading of pieces of pages. We can obviously make this very simple ("download some HTML from this URL and stick it in this div") or much more complex ("serialize this Haskell data structure to JSON, transfer it, parse it client side and build up the DOM tree").

Just forward and eval the string

"divName.innerHTML=\"text of th HTML to include\""

3) Perhaps not what you were thinking about, but easy integration with Javascript widgets. Here's an example: a photo gallery that has forward-next buttons. When Javascript is disabled, the server generates a new HTML page for each request. With Javascript enabled, it uses something like jquerytools.

This requires the detection of this condition. At the beginning, if the jscript code deoes not respond, ttoug the Ajax channel, then use HTML navigation.

Actually, it should work the opposite way, through graceful degradation. We send a webpage that operates perfectly with HTML alone, and link in a Javascript file that adds extra functionality.