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.
 
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.
 
These are the kinds of problems I was hoping to tackle with widgets. Let me know if this is not at all what you had in mind.

Michael


On Tue, Jun 22, 2010 at 6:27 PM, Alberto G. Corona <agocorona@gmail.com> wrote:
I forgot to cc this to the list. sorry


---------- Forwarded message ----------
From: Alberto G. Corona <agocorona@gmail.com>
Date: 2010/6/22
Subject: Re: [web-devel] missing web component needed: server-side page control
To: Michael Snoyman <michael@snoyman.com>


Hi Michael,
Great to know that you are interested!.

Good to know that you are working on widgets. I´m thinking about the same idea, but I ephasize the dynamic nature, that is , not only the widgets could be populated from haskell data structures, but will use the server side control to make them dynamic, so they can  interact with haskell server code without refreshing the whole page.

I tough on the need of an HTML DOM, because in my view,  we need a 1:1 mapping between the browser and the server in  XML manipulation primitives. Because Javascript uses HTML DOM. Much of HTML DOM methods are a single call to the corresponding XML DOM in HXT. But some other, like style manipulation are different. 

My idea is to have in the server a copy of the HTML tree. Any modification on the server will be forwarded to the client.  For example, the innerHTML method should be executed in the server as such:

setInnerHTML element text= 
       modify the local XML element with XML DOM
       if does not exist, exception raised
       if success, add "element.innerHTML= text" to the Ajax queue (the javascript listener will eval(uate) it in the client

having a local XML tree copy permits not only checking for errors in the server but also to query for document properties. referential transparency permits to share the unmodified XML branches for many client sessions. But I don´t went deep on thinking about it. neither I know the technology used in ASPX.NET of JavaServer Faces to do server control. It is really difficult to guess it doe to the confusing documentation. I can only guess  from the functionalities.  

Maybe we have to do a research on the best way to communicating client and server for server control, the methods to be used etc...



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

Sounds interesting. I just released Yesod 0.3.0, and had in mind that 0.4.0 will focus on a concept I was calling widgets. It sounds very similar to what you're talking about here, so I would definitely be interested in collaborating with you.

I'm not sure if writing DOM manipulation code ourselves is necessarily the right approach. It might make more sense to simply leverage an existing Javascript library (my personal preference being jQuery).

I have to get back to "real work" for the rest of the day, but I'd like to hear any other thoughts you have on the subject.

Michael

On Tue, Jun 22, 2010 at 2:23 PM, Alberto G. Corona <agocorona@gmail.com> wrote:
Hi web haskellers.
A few days ago I mention the need to have  server-side page control
available in Haskell. ASP.NET and JavaServer Faces have it.
I would like to collaborate with anyone of you interested. I have not
much time now but this can change in the coming weeks so I want to
know the interest on the subject in advance. I also want to receive
comments to the development plan.

The main advantages are:
  -No Javascript, no Ajax needed when developing dynamic HTML pages
(All code becomes pure haskell in the server!!)

 -No errors in advanced dynamic HTML code: all is statically typed
haskell (someone bets more?)

  -Clear separation of HTML presentation from page control code

  -Extensibility: makes possible to create custom controls, like HTML
tables automatically generated from haskell containers etc

All this will unleash the full power of haskell in the Web!!!

It is compatible and orthogonal with page templating and all other web
stuff. I think that it is a  two month work.

basically what we have to do is the following:

  0 develop a Haskell HTML DOM library. Just 31 objects to manage HTML trees
     See the HTML DOM Objects Reference at
http://www.w3schools.com/jsref/default.asp
      I suppose that this is not yet done
     Can make use of the XML structure defined in HXT
http://hackage.haskell.org/package/hxt-8.5.2. HXT has namespace
     support. This is needed for defining custom attributes and tags (4 and 5).

    each HTML DOM method will do two basic things:
          a) update a copy of the HTML page tree in the SERVER

          b) send trough an Ajax channel the equivalent javascript
method, that will be executed in the web browser

   3 create a minimum javascript module that:
        read Ajax responses and execute them in the web browser, for
the above functionality
        listen for events and forward them to the server trough Ajax.

   4 define additional XML attributes to be interspersed in the HTML tree for
       specifying url' s in the server where the server events will be
forwarded  (for 3)
          <button server:onclick="http://server/path...">

   5 a mechanism for defining custom XML tags for extensibility: with
the name, the parameters and the library code that handle it
     example of custom tag inserted in the HTML: <t:table
t:source="#{hasjkelldata} param1=......>

  6 some templating that read 5 and produces a HTML tree and Haskell code.


So, people, feel free to question anything. This is just the starting
point to put ideas in the table and discuss all of this
_______________________________________________
web-devel mailing list
web-devel@haskell.org
http://www.haskell.org/mailman/listinfo/web-devel




_______________________________________________
web-devel mailing list
web-devel@haskell.org
http://www.haskell.org/mailman/listinfo/web-devel