[web-devel] missing web component needed: server-side page control

[Michael Snoyman]

On Wed, Jun 23, 2010 at 9:01 PM, Alberto G. Corona <agocorona at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100624/87f2e6b7/attachment-0001.html