- web-devel - Haskell.org

Re: yesod stylesheet serving
by Michael Snoyman 06 Jul '10

06 Jul '10

On Mon, Jul 5, 2010 at 10:43 PM, Simon Michael <simon(a)joyful.com> wrote: > Great, thanks for the clarifications. sendFile made this easy. Has using > that affected my portability much, eg to windows ? As far as I know, not at all. I actually run some of this code on Windows system (via wai-handler-webkit[1]) in production environments, and it all works fine. I'm just building on top of the sendfile library[2] which does The Right Thing. Of course, like anything WAI, it depends on the implementation. If I'm not mistaken, Snap doesn't run on Windows (please correct me if I'm wrong on this, I'd like to know), so using the not-yet-released Snap WAI backend would clearly not work on Windows either. > > On Jul 5, 2010, at 12:04 PM, Michael Snoyman wrote: > >> the rendering details for you. If you point me to the code in question, >> I'll take a look. >> > > Latest code pushed to > http://joyful.com/darcsweb/darcsweb.cgi?r=hledger;a=headblob;f=/Hledger/Cli… > > Firstly, very nice code. I especially like how you're able to get an entire interface to fit into just 6 routes... impressive. I believe the problem is on line 120, where you call "renderHamlet id". If you look at the type of renderHamlet: renderHamlet :: (url -> String) -> Hamlet url -> L.ByteString You'll see that: renderHamlet id :: Hamlet String -> L.ByteString In general, you don't need to call renderHamlet directly when using Yesod. Instead, you have two better options: * hamletToRepHtml handles the rendering, calling toContent, and wrapping in a RepHtml. So your line 120 could be rewritten as: hamletToRepHtml $ template req msg as ps "hledger" s At which point you'd be able to use type-safe URLs in your Hamlet template (wrapping in the @ signs), and you can forget about URL splicing. * applyLayout just builds on top of hamletToRepHtml, by also applying your default layout to the returned content. In your case, I wouldn't say it's necessary, but it makes a lot of sense for large sites that want to have a standard look for all pages. Few other comments: * On line 228, you use a non-breaking space. I'm not sure if you *need* that, or are just trying to work around Yesod's whitespace rules. If the latter, there's a relatively new feature that allows you to put a backslash at the beginning of the content to bypass the whitespace rules.[3] * I'm impressed to see you found the getMessage/setMessage API. I keep meaning to blog about it, but haven't had a chance. * On line 212, I see you drop to plain XHTML syntax. If you just want to get XHTML closing-tag rules and keep the Hamlet syntax, use "$xhamlet" instead of "$hamlet" at the beginning of your quasi-quoter. Let me know if you have any other questions, I've been interested in hledger for a while now, so it's very gratifying to see it move over to Yesod. Michael [1] http://hackage.haskell.org/package/wai-handler-webkit [2] http://hackage.haskell.org/package/sendfile [3] http://docs.yesodweb.com/hamlet/lineparsing.html

2 5

bird: a simple haskell web framework
by Matt Parker 06 Jul '10

06 Jul '10

hi, i'm making a simple haskell web framework, "bird". check it out on github if you're interested. the project is still in its infancy - and i'm still learning haskell :-) http://github.com/moonmaster9000/bird

1 0

Re: yesod stylesheet serving
by Michael Snoyman 05 Jul '10

05 Jul '10

On Mon, Jul 5, 2010 at 10:01 PM, Michael Snoyman <michael(a)snoyman.com>wrote: > Hey Simon, > > Firstly, I'm not sure if your message went through to the rest of the list, > but at least they should see this reply. > > On Mon, Jul 5, 2010 at 8:02 PM, Simon Michael <simon(a)joyful.com> wrote: > >> Hi Michael.. thanks again for the great real-world-driven updates to Yesod >> et al. I'm looking forward to trying widgets. Meanwhile... >> >> I'm having trouble serving a stylesheet that Chrome will recognise, >> because this: >> >> getStyleCss :: Handler HledgerWebApp RepPlain >> getStyleCss = do >> app <- getYesod >> let dir = appWebdir app >> s <- liftIO $ readFile $ dir </> "style.css" >> header "Content-Type" "text/css" >> return $ RepPlain $ toContent s >> >> serves up this: >> >> $ curl -i http://localhost:5000/style.css >> HTTP/1.1 200 OK >> Content-Type: text/plain; charset=utf-8 >> Set-Cookie: _SESSION=...; path=/; expires=2010-07-05T18:41:35-00:00 >> Content-Type: text/css >> >> Note the two content-types. (Also, no content-length header; I don't know >> if that matters.) >> >> Let me explain. In general, you don't need to explicitly set content-type > headers in Yesod. Yesod determines the content type automatically based on > the return type of the handler function. In particular, a handler must > return an instance of HasReps, which allows a handler to specify multiple > representations of data if it so desires. > > By using a return type of RepPlain, you're telling Yesod to set a > content-type header of "text/plain". Instead, you probably want to use a > different return type. For example, you could use the [(ContentType, > Content)] return type. > > However, in your case, you have two much better options (in my opinion): > > * Use the Static helper. > * Use the sendFile function. When using sendFile, you short-circuit the > remainder of the handler code and immediately send a file. You get to > explicitly state the content type, and also get another bonus: some backends > optimize the sending of static files. For example, the SimpleServer backend > using a sendfile system call, so you avoid unnecessary data copying. > > Your examples seem to serve css using Yesod.Helpers.Static. I'm not using >> that because it seems to require a file path known at compile time, or am I >> wrong ? I get the path at run-time with cabal's getDataFilename. >> >> No, the path does not need to be known at compile time, but you'll need to > supply it when constructing the Static data type value. All of this would > happen when initializing your site argument; I can put together an example > of this if you like. > > And an unrelated question: what's the meaning of the type returned by a >> hamlet template ? I see one of your examples returning something like Hamlet >> AppRoutes, but my app will accept only Hamlet String for some reason. I >> wouldn't worry except hamletToRepHtml seems to require the former. >> >> type Hamlet url = (url -> String) -> Html () > > The Html is a datatype taken from Blaze, which is what let's Hamlet get all > of the performance advantages of that library. The url has to do with the > type-safe URL feature: every site has a URL datatype associated with it, > which defines all valid routes into an application. Of course, we can't just > display Haskell datatypes in our HTML code, so Hamlet takes a "url rendering > function" as its first argument. > > In general, you shouldn't need to be bothered with any of these details, as > Yesod automates all of the rendering details for you. If you point me to the > code in question, I'll take a look. > > Michael >

1 0

haskell web development with a restricted shell account
by Markus Läll 03 Jul '10

03 Jul '10

Hi! I have a noobish question -- what are my chances of doing web development on a host, where I have restricted shell access? Like, if I can copy programs to my own folders, then I could also copy a version of GHC and run that with my .hs files through a cgi folder, or maybe I could compile my programs and copy those executables to the cgi folder? Markus

4 3

An idea for Yesod, feedback requested
by Michael Snoyman 30 Jun '10

30 Jun '10

I'm adding some support right now to Yesod (for version 0.4.0) to support some operations at the beginning of each handler. In particular, the onRequest and isAuthorized functions will now both run inside the Handler monad for each request, giving them full access to all data available there. In addition, the defaultLayout and errorHandler functions both live in the Handler monad. I have an idea to add a per-request piece of data which would be application defined. As a motivating example, a common task would be to check if a user is logged in (by checking the user session), and if he/she is logged in, grab some extra data from the database, such as display name. My idea would use type families to store that kind of information inside the Handler. One benefit is encapsulating this database loading code in one location; however, that could easily be accomplished by just writing a function to do it for you, and calling that function from all your handlers. However, there's a much larger benefit: let's say that you want information on the display name in both the applyLayout function and your handler function; currently, you'd need to do two database lookups. Now, you'd just need one. There are two downsides I can see. The first is that this kind of loading code will be performed at each request, even if it's not used. I'm not as worried about that issue, since most of the time it's data that will be used in the applyLayout function, which is called on almost every request. The second issue is a code style issue: since there seems to be no way to declare default type synonym instances, I'd need to add to more required entries into the Yesod typeclass: the type synonym instances, and the loader function. Currently, the only required function in the Yesod typeclass is approot, and I'm particularly worried about adding some lines requiring the usage of type families, as many users are unfamiliar with them. A possible method for mitigating this issue is to include a scaffolding tool with Yesod that will string up a default site. That's probably something I'll end up doing anyway. Appreciate any user feedback! Michael

1 0

Fwd: [web-devel] missing web component needed: server-side page control
by Alberto G. Corona 24 Jun '10

24 Jun '10

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(a)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(a)gmail.com>wrote: > >> I forgot to cc this to the list. sorry >> >> >> ---------- Forwarded message ---------- >> From: Alberto G. Corona <agocorona(a)gmail.com> >> Date: 2010/6/22 >> Subject: Re: [web-devel] missing web component needed: server-side page >> control >> To: Michael Snoyman <michael(a)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(a)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(a)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(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/web-devel >>>> >>> >>> >> >> >> _______________________________________________ >> web-devel mailing list >> web-devel(a)haskell.org >> http://www.haskell.org/mailman/listinfo/web-devel >> >> >

2 1

missing web component needed: server-side page control
by Alberto G. Corona 23 Jun '10

23 Jun '10

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

6 5

Re: [web-devel] Wiki web programming page(s)
by Michael Snoyman 23 Jun '10

23 Jun '10

OK, I've started working on the new structure, and put it on the "Web" page on the wiki[1]. I've added so far the section on interfaces (Hack and WAI), so there's clearly more to go, but I wanted to see if people like/hate the format before investing a lot of time in it. Michael [1] http://haskell.org/haskellwiki/Web On Mon, Jun 21, 2010 at 6:09 PM, Thomas Hartman < thomashartman1(a)googlemail.com> wrote: > I meant full fledged demo car keys-included, when they are available :) > > Otherwise yes sample code. Something to give the flavor of what is to > come, and also to help the total newbie sense how much community / > momentum there is going (and maybe enchant them a bit). > > Whether on the main page or somewhere quick to pop up, fine, just > wanted to emphasize that this is something I look for first. > > > On Mon, Jun 21, 2010 at 7:53 AM, Michael Snoyman <michael(a)snoyman.com> > wrote: > > Do you mean sample code, or sample full-fledged apps? Either way, I don't > > think it make sense to have it on the main page, but trying to have a > link > > to sample code for each library seems like a very good idea. > > > > On Mon, Jun 21, 2010 at 5:49 PM, Thomas Hartman > > <thomashartman1(a)googlemail.com> wrote: > >> > >> Personally the first thing I look for is a sample app(s), so I would > >> include this prominently in the thinking somehow. > >> > >> On Mon, Jun 21, 2010 at 7:15 AM, Michael Snoyman <michael(a)snoyman.com> > >> wrote: > >> > Inspiration for this e-mail comes from a post on reddit[1]. > >> > I think it's time as a web development community we work together on > the > >> > overall Haskell web brand. We need a well thought out approach to > >> > organizing > >> > the information we have on the Wiki, and some people to be responsible > >> > for > >> > keeping it up to date. At the moment, the main web programming page[2] > >> > is > >> > (in my opinion) horribly disorganized, and presents the wrong > >> > information > >> > first. We also have a number of smaller pages floating around > [3][4][5] > >> > that > >> > in theory could be subsumed into a more general framework. > >> > > >> > The first step I believe is to create a single page that categorizes > all > >> > of > >> > the web projects, gives a brief description, and links to more > >> > information. > >> > One thing this main page should *not* do is give information like how > to > >> > create a static binary[6]. > >> > So here's a start at the categories I think we should put in: > >> > Servers, eg happstack, snap > >> > Interfaces, eg Hack, WAI. Perhaps it should be included in servers? > >> > Templating: HStringTemplate, Hamlet, HSP > >> > HTML combinators: blaze, html, xhtml. Perhaps included in templating? > >> > Storage: HDBC, macid > >> > Controllers: web-routes, UrlDisp > >> > Frameworks: yesod, kibro, turbinado, happstack, snap > >> > Misc: authenticate, openid, clientsession > >> > Let's try to get a single page that contains as much of a high-level > >> > overview as possible. Just imagine if people new to Haskell could go > to > >> > one > >> > page, get up-to-date information and make informed decisions about > their > >> > choice in tools. > >> > Michael > >> > > >> > [1] > http://www.reddit.com/r/haskell/comments/ch4me/first_impressions_serving_st… > >> > > >> > [2] > http://www.haskell.org/haskellwiki/Practical_web_programming_in_Haskell > >> > [3] http://www.haskell.org/haskellwiki/Web > >> > > >> > [4] > http://www.haskell.org/haskellwiki/Applications_and_libraries/Web_programmi… > >> > [5] http://www.haskell.org/haskellwiki/Blog_articles/Web > >> > [6] > >> > _______________________________________________ > >> > web-devel mailing list > >> > web-devel(a)haskell.org > >> > http://www.haskell.org/mailman/listinfo/web-devel > >> > > >> > > >> > >> > >> > >> -- > >> Need somewhere to put your code? http://patch-tag.com > >> Want to build a webapp? http://happstack.com > > > > > > _______________________________________________ > > web-devel mailing list > > web-devel(a)haskell.org > > http://www.haskell.org/mailman/listinfo/web-devel > > > > > > > > -- > Need somewhere to put your code? http://patch-tag.com > Want to build a webapp? http://happstack.com >

2 1

Fwd: [web-devel] missing web component needed: server-side page control
by Alberto G. Corona 22 Jun '10

22 Jun '10

I forgot to cc this to the list. sorry ---------- Forwarded message ---------- From: Alberto G. Corona <agocorona(a)gmail.com> Date: 2010/6/22 Subject: Re: [web-devel] missing web component needed: server-side page control To: Michael Snoyman <michael(a)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(a)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(a)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(a)haskell.org >> http://www.haskell.org/mailman/listinfo/web-devel >> > >

3 2

Re: [web-devel] Wiki web programming page(s)
by Michael Snoyman 21 Jun '10

21 Jun '10

Do you mean sample code, or sample full-fledged apps? Either way, I don't think it make sense to have it on the main page, but trying to have a link to sample code for each library seems like a very good idea. On Mon, Jun 21, 2010 at 5:49 PM, Thomas Hartman < thomashartman1(a)googlemail.com> wrote: > Personally the first thing I look for is a sample app(s), so I would > include this prominently in the thinking somehow. > > On Mon, Jun 21, 2010 at 7:15 AM, Michael Snoyman <michael(a)snoyman.com> > wrote: > > Inspiration for this e-mail comes from a post on reddit[1]. > > I think it's time as a web development community we work together on the > > overall Haskell web brand. We need a well thought out approach to > organizing > > the information we have on the Wiki, and some people to be responsible > for > > keeping it up to date. At the moment, the main web programming page[2] is > > (in my opinion) horribly disorganized, and presents the wrong information > > first. We also have a number of smaller pages floating around [3][4][5] > that > > in theory could be subsumed into a more general framework. > > > > The first step I believe is to create a single page that categorizes all > of > > the web projects, gives a brief description, and links to more > information. > > One thing this main page should *not* do is give information like how to > > create a static binary[6]. > > So here's a start at the categories I think we should put in: > > Servers, eg happstack, snap > > Interfaces, eg Hack, WAI. Perhaps it should be included in servers? > > Templating: HStringTemplate, Hamlet, HSP > > HTML combinators: blaze, html, xhtml. Perhaps included in templating? > > Storage: HDBC, macid > > Controllers: web-routes, UrlDisp > > Frameworks: yesod, kibro, turbinado, happstack, snap > > Misc: authenticate, openid, clientsession > > Let's try to get a single page that contains as much of a high-level > > overview as possible. Just imagine if people new to Haskell could go to > one > > page, get up-to-date information and make informed decisions about their > > choice in tools. > > Michael > > [1] > http://www.reddit.com/r/haskell/comments/ch4me/first_impressions_serving_st… > > [2] > http://www.haskell.org/haskellwiki/Practical_web_programming_in_Haskell > > [3] http://www.haskell.org/haskellwiki/Web > > [4] > http://www.haskell.org/haskellwiki/Applications_and_libraries/Web_programmi… > > [5] http://www.haskell.org/haskellwiki/Blog_articles/Web > > [6] > > _______________________________________________ > > web-devel mailing list > > web-devel(a)haskell.org > > http://www.haskell.org/mailman/listinfo/web-devel > > > > > > > > -- > Need somewhere to put your code? http://patch-tag.com > Want to build a webapp? http://happstack.com >

1 0