Inspired by the ease with which Joe Gregorio put together a framework in Python using some components [1] I'm inspired to create some components of my own so the same thing can be done in Haskell. I'm aiming for creating some thing /really/ simple and I want to start with writing a templating system or a database wrapper. But first, what has been done in this area already already? I'm aware of at least some template like efforts [2]. For the templating system I don't think I want a DSL like approach (ala Lisp with (body (h1 "Foo")) etc. but rather a solution where code and templates are kept separate. Here's a really simple interface. compileTemplate :: Stringable a => a -> Template renderTemplate :: (Show a, Stringable b) => Template -> Map Stringable a -> b Or something along those lines. Compiling the template makes subsequent rendering faster and ByteString adds even more speed. With some templating language like so: <html> <head>...</head> <body> <h1>{{ title }}</h1> </body> </html> 'title' is looked up in the Map when the template is rendered. The other option would be inline Haskell code: <html> <head>...</head> <body> <h1><% postTitle title %></h1> </body> </html> Where 'title' is a record data type. There's also a middle ground like with Django's templates that supports restricted inline code. I guess the restriction is unnecessary in Haskell as we can disallow mutation of values quite easily (?). 1. http://bitworking.org/news/Why_so_many_Python_web_frameworks 2. http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-str...
On 3/29/07, Johan Tibell
I want to start with writing a templating system or a database wrapper. But first, what has been done in this area already already?
There was recent announcement on the Haskell lists about "Chunks". (http://www.wellquite.org/index.php/chunks/) This sounds like something you described. I've only played with the examples given, so I don't know how well it scales on a larger project. -- Rich AIM : rnezzy ICQ : 174908475 Jabber: rich@neswold.homeunix.net
I'm interested in seeing something like this too. However, I am a big fan of DSL, especially if they're designed correctly. The crux to having a good DSL is thinking: "How do I *really* want to write this?", and starting from there on. I haven't really thought about those things for a web-framework yet. -chris On Mar 29, 2007, at 10:48 AM, Johan Tibell wrote:
Inspired by the ease with which Joe Gregorio put together a framework in Python using some components [1] I'm inspired to create some components of my own so the same thing can be done in Haskell. I'm aiming for creating some thing /really/ simple and I want to start with writing a templating system or a database wrapper. But first, what has been done in this area already already? I'm aware of at least some template like efforts [2]. For the templating system I don't think I want a DSL like approach (ala Lisp with (body (h1 "Foo")) etc. but rather a solution where code and templates are kept separate. Here's a really simple interface.
compileTemplate :: Stringable a => a -> Template renderTemplate :: (Show a, Stringable b) => Template -> Map Stringable a -> b
Or something along those lines. Compiling the template makes subsequent rendering faster and ByteString adds even more speed.
With some templating language like so:
<html> <head>...</head> <body> <h1>{{ title }}</h1> </body> </html>
'title' is looked up in the Map when the template is rendered. The other option would be inline Haskell code:
<html> <head>...</head> <body> <h1><% postTitle title %></h1> </body> </html>
Where 'title' is a record data type. There's also a middle ground like with Django's templates that supports restricted inline code. I guess the restriction is unnecessary in Haskell as we can disallow mutation of values quite easily (?).
1. http://bitworking.org/news/Why_so_many_Python_web_frameworks 2. http://blog.moertel.com/articles/2006/10/18/a-type-based- solution-to-the-strings-problem _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
On 30/03/07, Chris Eidhof
I'm interested in seeing something like this too. However, I am a big fan of DSL, especially if they're designed correctly. The crux to having a good DSL is thinking: "How do I *really* want to write this?", and starting from there on. I haven't really thought about those things for a web-framework yet.
I'd agree with this. Haskell is astonishingly expressive and can support all kinds of levels of EDSLs. I've been writing forum software in Haskell and came across this decision: do I write my templates in HTML + some code or in Haskell? I couldn't really see any disadvantages to the latter, and the advantages were obviously that I got all the traditional Haskell functions and features, and so on. I still maintain a fairly strict MVC structure within the application; the controllers compute the necessary parameters for the templates and pass them in. For reference, here's one of my templates: -- | The 'V' monad, in which our viewers execute. type V a = WriterT ViewOut (Reader ViewEnv) a type Viewer = V Html -- | View the public profile of a user. vUser :: User -> Viewer vUser u = do tell $ VO { voTitle = usrDisplay u, voBreadcrumbs = singleton indexLink } usr <- asks veUser let hdr = h2 << usrDisplay u dfns = [("Name: ", primHtml $ usrDisplay u), ("Registered at: ", primHtml $ renderCalTime (usrRegistered u)), ("Url: ", toHtml $ hotlink (usrUrl u) << usrUrl u), ("Blurb: ", primHtml $ usrBlurb u)] del = whenPermitted usr RmUser $ hotlink (userUrl u ++ "/delete") << "Delete user" return $ hdr +++ defList dfns +++ cappedOps [del] -- -David House, dmhouse@gmail.com
David, Why do you want to embed Haskell code in templates? Why not go with an approach like Zope TAL? Thanks, Joel -- http://wagerlabs.com/
On 05/04/07, Joel Reymont
Why do you want to embed Haskell code in templates?
Why add another dependency, force your coders to learn another language, restrict yourself to a language which isn't as expressive as Haskell, reduce your ability to reuse code from different areas of the project and decrease project-wide consistency when you could just write your templates in Haskell to begin with? Haskell is the king of EDSL. Let's take advantage of that. -- -David House, dmhouse@gmail.com
On Apr 5, 2007, at 2:51 PM, David House wrote:
Why add another dependency, force your coders to learn another language, restrict yourself to a language which isn't as expressive as Haskell, reduce your ability to reuse code from different areas of the project and decrease project-wide consistency when you could just write your templates in Haskell to begin with?
Embedding code in web templates doesn't work well when you have designers on board. Let me elaborate on my approach as it doesn't reduce or restrict anything! I'm suggesting that you make your templates look like this, which is parseable as XML. Note the "tal:" tags. Please scroll through to the bottom for more thoughts. <?xml version="1.0" encoding="ISO-8859-1"?> <html> <head> <title tal:content="page/title">Page title</title> </head> <body> <h1 tal:content="page/title">Heading</h1> <p> Hello <b tal:omit-tag="visitor/humble"><span tal:replace="visitor/name">wo rld</span></b> </p> <p tal:condition="msg page/message" tal:content="msg">Message</p> <ul> <li>Hard-coded</li> <li tal:define="users page/users" tal:repeat="item users" tal:content="ite m/name">Dummy</li> </ul> <p tal:condition="page/renderfooter"> Back to <a href="#" tal:define="up page/up" tal:attributes="href up/ href;title up/ title">index</a> </p> </body> </html> The above expands into this: <html> <head> <title>Demo page</title> </head> <body> <h1>Demo page</h1> <p> Hello <b>Bruno</b> </p> <p>(c) 2006</p> <ul> <li>Hard-coded</li> <li>Xavier</li> <li>Damien</li> <li>Jacques</li> <li>Didier</li> <li>Jerome</li> </ul> <p> Back to <a title="Caml Home" href="http://caml.inria.fr/">index</a> </p> </body> </html> Note how <ul> <li>Hard-coded</li> <li tal:define="users page/users" tal:repeat="item users" tal:content="ite m/name">Dummy</li> </ul> is expanded to <ul> <li>Hard-coded</li> <li>Xavier</li> <li>Damien</li> <li>Jacques</li> <li>Didier</li> <li>Jerome</li> </ul> This is nice and _very_ clean and allows you to use any Haskell code you want to _process_ the template. You can, in fact, make template processing recursive and have tags produce more tags, i.e. make your components produce HTML instead of data for tags in the template. What do you think? -- http://wagerlabs.com/
Embedding code in web templates doesn't work well when you have designers on board.
That's not necesarily true. Templates where there is mostly markup, but let
you embed code into them using special tags (ex, <% code %>) are extremely
popular and work fairly well. They also keep the template language simple
because there is already a full-powered programming language thats embedded
into it. Good examples of this method are ERB templates in Rails, JSPs, Perl
Mason templates, etc.
In these cases one of two things happen: either the designers learn enough
of the programming language to embed the right things in, or they just hand
off HTML to the developers, who can then replace the dynamic parts with <%
%> tags. If I'm a designer and I have learn a new templating language
anyway, I may as well just learn a little bit of
Haskell/Ruby/Perl/Java/whatever.
The best choice of templating technology really depends who the target
audience of the web framework is. Has there been much thought given to that
yet?
Maurice
On 4/5/07, Joel Reymont
On Apr 5, 2007, at 2:51 PM, David House wrote:
Why add another dependency, force your coders to learn another language, restrict yourself to a language which isn't as expressive as Haskell, reduce your ability to reuse code from different areas of the project and decrease project-wide consistency when you could just write your templates in Haskell to begin with?
Embedding code in web templates doesn't work well when you have designers on board.
Let me elaborate on my approach as it doesn't reduce or restrict anything!
I'm suggesting that you make your templates look like this, which is parseable as XML. Note the "tal:" tags. Please scroll through to the bottom for more thoughts.
<?xml version="1.0" encoding="ISO-8859-1"?> <html> <head> <title tal:content="page/title">Page title</title> </head> <body> <h1 tal:content="page/title">Heading</h1> <p> Hello <b tal:omit-tag="visitor/humble"><span tal:replace="visitor/name">wo rld</span></b> </p> <p tal:condition="msg page/message" tal:content="msg">Message</p> <ul> <li>Hard-coded</li> <li tal:define="users page/users" tal:repeat="item users" tal:content="ite m/name">Dummy</li> </ul> <p tal:condition="page/renderfooter"> Back to <a href="#" tal:define="up page/up" tal:attributes="href up/ href;title up/ title">index</a> </p> </body> </html>
The above expands into this:
<html> <head> <title>Demo page</title> </head> <body> <h1>Demo page</h1> <p> Hello <b>Bruno</b> </p> <p>(c) 2006</p> <ul> <li>Hard-coded</li> <li>Xavier</li> <li>Damien</li> <li>Jacques</li> <li>Didier</li> <li>Jerome</li> </ul> <p> Back to <a title="Caml Home" href="http://caml.inria.fr/">index</a> </p> </body> </html>
Note how
<ul> <li>Hard-coded</li> <li tal:define="users page/users" tal:repeat="item users" tal:content="ite m/name">Dummy</li> </ul>
is expanded to
<ul> <li>Hard-coded</li> <li>Xavier</li> <li>Damien</li> <li>Jacques</li> <li>Didier</li> <li>Jerome</li> </ul>
This is nice and _very_ clean and allows you to use any Haskell code you want to _process_ the template. You can, in fact, make template processing recursive and have tags produce more tags, i.e. make your components produce HTML instead of data for tags in the template.
What do you think?
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
Do you see anything wrong with the approach I suggested, though? On Apr 5, 2007, at 6:16 PM, Maurice Codik wrote:
) are extremely popular and work fairly well. They also keep the template language simple because there is already a full-powered
That's not necesarily true. Templates where there is mostly markup, but let you embed code into them using special tags (ex, <% code % programming language thats embedded into it. Good examples of this method are ERB templates in Rails, JSPs, Perl Mason templates, etc.
A few things, some of which I sort of mentioned in my previous email:
- If I'm already going to commit some time to learn a templating language,
why dont I just spend that same amount of time learning the little bit of
haskell I need to make the template work? If thats too much to ask, I can
just spit out HTML, and have the programmer put in the dynamic parts for me.
Both of these scenarios seem to be a more efficient use of time.
- Who is the target audience? If its a big organization where there are
multiple designers and multiple devs, then your approach may work just fine.
If its the single developer, then something like what David suggested would
work even better. If its a small team (which may or may not include a
full-time designer), then something like what I suggested would work best.
For a web framework for haskell, I would guess that the latter two are much
more likely.
- Embedding a real programming language in a template already gives you
power to do what ever you need to do. What if you need to implement some
logic that the template language doesnt support? In those cases, you're
usually out of luck and have to move that logic into a controller, where it
doesnt really belong (assuming its actual display logic, not business
logic).
- It's really just a matter of taste. Any web framework thats worth using
should be flexible in its support of view technologies, but come with one
thats a sensible default.
Maurice
On 4/5/07, Joel Reymont
Do you see anything wrong with the approach I suggested, though?
On Apr 5, 2007, at 6:16 PM, Maurice Codik wrote:
) are extremely popular and work fairly well. They also keep the template language simple because there is already a full-powered
That's not necesarily true. Templates where there is mostly markup, but let you embed code into them using special tags (ex, <% code % programming language thats embedded into it. Good examples of this method are ERB templates in Rails, JSPs, Perl Mason templates, etc.
Let me through Avi Bryant's recent slides into the conversation: http://smallthought.com/avi/etech.pdf Some things that I think, some of which overlap with what Avi's saying: 1) Programmatic generation of content is good. Interaction with designers can be managed simply -- select CSS as the primary means of customizing display, settle on prototype HTML for the designers to work with, generate the HTML programmatically to that prototype as a spec. 2) Templating is ugly. Debugging and testing are difficult. Templating is antipodal to separation of concerns. I'd like us to brainstorm on a couple of topics: A) How do we leverage what is special about Haskell -- laziness, types, purity -- to create an effective and simple web framework? B) What's wrong with existing web frameworks (RoR, straight JSP, PHP, etc.)? For my money, the things that are wrong with RoR and friends is that they let you write really awful software -- even *force* you to do so by the decomposition into templates, controllers, etc. Which brings us back to question A. -- paulrbrown@gmail.com http://mult.ifario.us/
My priorities: * Make storage and client stuff transparent to server side developer * Use in memory haskell data structures to represent state. + rely on MACID for persistence + no type errors from app/db inconsistency + isolate schema change risk to deserialization from disk + no need for extra mem-cache plumbing! * Atomatic conversion to/from wire format types to haskell data types in my app. Auto-parse/generate JSON/XML/URLEncode. * Scaling should be really really easy * easy integration of multi-protocol services e.g. IRC, SMTP, HTTP in one app. See HPaste and Pass.net. * develop in Haskell. -Alex- On Thu, 5 Apr 2007, Paul Brown wrote:
Let me through Avi Bryant's recent slides into the conversation:
http://smallthought.com/avi/etech.pdf
Some things that I think, some of which overlap with what Avi's saying:
1) Programmatic generation of content is good. Interaction with designers can be managed simply -- select CSS as the primary means of customizing display, settle on prototype HTML for the designers to work with, generate the HTML programmatically to that prototype as a spec.
2) Templating is ugly. Debugging and testing are difficult. Templating is antipodal to separation of concerns.
I'd like us to brainstorm on a couple of topics:
A) How do we leverage what is special about Haskell -- laziness, types, purity -- to create an effective and simple web framework?
B) What's wrong with existing web frameworks (RoR, straight JSP, PHP, etc.)?
For my money, the things that are wrong with RoR and friends is that they let you write really awful software -- even *force* you to do so by the decomposition into templates, controllers, etc. Which brings us back to question A.
-- paulrbrown@gmail.com http://mult.ifario.us/ _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
participants (8)
-
Chris Eidhof -
David House -
Joel Reymont -
Johan Tibell -
Maurice Codik -
Paul Brown -
Rich Neswold -
S. Alexander Jacobson