On Thu, May 27, 2010 at 8:31 PM, Matt Parker <moonmaster9...@gmail.com> 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 <moonmaster9...@gmail.com> 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 <moonmaster9...@gmail.com> > 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 <agocor...@gmail.com> >> 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 <jasper...@gmail.com> >>>> >>>> Hey Bas, >>>> >>>> > How about also providing an enumerator back-end? >>>> > >>>> > http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Iteratee-Base.html#t%3AEnumeratorGM >>>> > >>>> > 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 <v.dijk....@gmail.com> >>>> 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-Iteratee-Base.html#t%3AEnumeratorGM >>>> > >>>> > 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-de...@haskell.org >>> http://www.haskell.org/mailman/listinfo/web-devel >>> >> > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe