missing web component needed: server-side page control
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
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
Hi! This is definitely the right way. Current set of related technologies includes Formlets, HJScript, Web-routes, various template systems like Hamlet or HSX.
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.
Ajax is just one approach of several existing. Building a haskell-to-JavaScript generator looks more important for me. Please look at [1] and [2]. what do you think? Generally, it is already possible to manage client java-scripts on the server with HSX + HJScript [3]. On the other hand, managing pure html forms for JScript-free apps is possible with the help of Formlets. But when one starts using them all together, code becomes awkward. [1] http://www.haskell.org/haskellwiki/Haskell_in_web_browser [2] http://vir.mskhug.ru/ [3] http://git.ierton.ru/?p=happstack-samples.git;a=blob_plain;f=HJSample.hs;hb=... -- Thanks, Sergey
Hello,
Ajax is just one approach of several existing. Building a haskell-to-JavaScript generator looks more important for me. Please look at [1] and [2]. what do you think?
For generating Javascript from Haskell, there is also the jmacro package (on Hackage). I am probably to main user of jmacro; we use it at work to generate a very non-trivial front end for a web-based system (backend uses happstack). Some advantages of jmacro are: a nice syntax, shared variable namespace for haskell and generated javascript (which also allows hygienic variable name generation, i.e. variable scoping is correct), embedding of pure haskell inside jmacro code blocks (this is particularly useful with the shared variable names). Some disadvantages of jmacro are: it is untyped, in fact most valid javascript can be placed in a jmacro block unchanged (this can also be an advantage since your favorite javascript library can be seamlessly integrated with your jmacro produced javascript); it is under documented (but the maintainer and I would certainly be happy to answer questions). Here is a small reddit thread about jmacro: http://www.reddit.com/r/haskell/comments/b1q1z/jmacro_quasiquotation_library... -Jeff
Neat, I'll be taking a look at jmacro.
I have been experimenting with a Widget system based on HSX+HJScript. The biggest issue I have run into seems to be marshaling your data between Haskell and Javascript. The problem is that the two languages offer fairly different and incompatible data representations. But you often want to send data back and forth between the client (javascript) and server (Haskell). You have 5 choices, that I can think of: 1. Use nice algebraic types. This makes your Haskell code nice, but working with algebraic types in javascript is a pain. [1] 2. Use objects (json) for your types. This makes the javascript easier to work with, but is a type mess in Haskell and not easy to work with. 3. Use algebraic types in Haskell, and Objects in javascript. This makes the data easy to work with in both language, but you have to be able to convert from one style to another. In my opinion, that requires writing both representations by hand and the marshaling functions by hand. Then anytime you change the type, you have to change both types (the haskell and javascript versions) and update the marshal functions. There is also no guarantee that you did any of it right with out testing. 4. Create a DSL for defining types which automatically generates the Haskell/javascript datatypes. This would presumably use a fairly limited set of types such that the types it generates are 'friendly' to use in both the Haskell and javascript-side. The drawback is that it is likely to be restrictive enough that it is not especially nice to use in either language. (Likely to be somewhat verbose I think...) 5. Compile haskell-to-javascript (or something along those lines), so that you only think in Haskell and don't have to think about javascript or javascript types. This is nice because you only have to think in one language, etc. But performance of the javascript code is a concern. And it makes it difficult to leverage existing javascript libraries like jQuery (because jquery is going to want javascripty types, etc). I'd like to hear about other options, or implementations of those options that work well.. - jeremy I have not tried using this algrebraic data type library for javascript yet.. because I just remembered it existed. [1] http://w3future.com/weblog/stories/2008/06/16/adtinjs.xml On Jun 22, 2010, at 8:53 AM, Sergey Mironov wrote:
Hi! This is definitely the right way. Current set of related technologies includes Formlets, HJScript, Web-routes, various template systems like Hamlet or HSX.
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.
Ajax is just one approach of several existing. Building a haskell-to-JavaScript generator looks more important for me. Please look at [1] and [2]. what do you think?
Generally, it is already possible to manage client java-scripts on the server with HSX + HJScript [3]. On the other hand, managing pure html forms for JScript-free apps is possible with the help of Formlets. But when one starts using them all together, code becomes awkward.
[1] http://www.haskell.org/haskellwiki/Haskell_in_web_browser [2] http://vir.mskhug.ru/ [3] http://git.ierton.ru/?p=happstack-samples.git;a=blob_plain;f=HJSample.hs;hb=...
-- Thanks, Sergey _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
participants (6)
-
Alberto G. Corona -
jeff p -
Jeremy Shaw -
Michael Snoyman -
Sergey Mironov -
Simon Michael