On Thu, May 27, 2010 at 8:31 PM, Matt Parker wrote:

will it be possible to easily interleave IO values into the HTML? like instead of the [1,2,3]

ul $ forM_ [1, 2, 3] (li . string . show)

what if it was a function that returned IO [1,2,3] (maybe 1,2,3 came out of a database). will the forM_ handle that OK?

Depends on how you write the code. More precisely, it depends on in which monad the forM_ takes place. Also, I would not recommend interleaving IO values into the HTML, because the HTML is pure -- you usually don't want to mix that with IO. I'd rather write something like: numbers <- getFromDataBase return $ ul $ forM_ numbers (li . string . show) Or it could be possible to store your templates in a separate modules, and they would all have a pure type signature: templateX :: Arg1 -> Arg2 -> Html a I think this would be the preferred way, because it allows a separation between the pure View code and the IO-interleaved Controller code in a web application. Kind regards, Jasper Van der Jeugt On Thu, May 27, 2010 at 8:31 PM, Matt Parker wrote:

will it be possible to easily interleave IO values into the HTML? like instead of the [1,2,3]

ul $ forM_ [1, 2, 3] (li . string . show)

what if it was a function that returned IO [1,2,3] (maybe 1,2,3 came out of a database). will the forM_ handle that OK?

On Thu, May 27, 2010 at 12:19 PM, Matt Parker wrote:

...

Blaze HTML looks wonderful to me (especially with the do notation), and better then Hamlet for one reason: writing idiomatic haskell for stuff like this:

ul $ forM_ [1, 2, 3] (li . string . show)

instead of the Hamlet style:

%ul $forall children.person child %li $child$

which, i don't know, for some reason, made me feel like i was back in PHP land.

-matt

On Thu, May 27, 2010 at 7:08 AM, Alberto G. Corona wrote:

...

As a user, I have too many HTML generators, a few of them with Ajax and none with server-side event handling (like ASPX or JSPX).  Ajax is complicated but server side event handling is  what I really miss because it is simple  from the user point of view, my ervents could be handled in haskell code rather than in javaScript and I  implicitly could  use the advantages of  dinamic HTML and Ajax without the need to know them at all. Imagine a dynamic Web application  with 100% haskell code made with dynamic widgets created by third party developers. So, anyone want to create a HTML templating system with server side event handling? It is not terribly hard to do. (I refer to ASP.NET documentation or the JavaServer Faces framework). By the way, I vote for XML templating or else, combinator templating that produce XHML templating because it can be handled by a future graphical IDE.

2010/5/27 Jasper Van der Jeugt

...

Hey Bas,

...

How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

Then your library can integrate more easily with the snap framework: http://snapframework.com

Sure, I can do that. But I already tested integration with the snap framework, the best path here seems to call the `writeLBS` function from the snap framework on the `L.ByteString` that BlazeHtml produces (`writeLBS` internally uses an enumerator).

Kind regards, Jasper Van der Jeugt

On Thu, May 27, 2010 at 10:38 AM, Bas van Dijk wrote:

...

Q14: Do you see any problems with respect to integrating BlazeHtml in your favourite web-framework/server?

How about also providing an enumerator back-end?

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Ite...

Then your library can integrate more easily with the snap framework: http://snapframework.com

Regards,

Bas

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

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