- web-devel - Haskell.org

Fwd: proposal for hamlet-like syntax that is more compatible with html
by Michael Snoyman 13 Dec '10

13 Dec '10

Sorry, forgot to reply to all... ---------- Forwarded message ---------- From: Michael Snoyman <michael(a)snoyman.com> Date: Sun, Dec 12, 2010 at 6:54 PM Subject: Re: [web-devel] proposal for hamlet-like syntax that is more compatible with html To: Greg Weber <greg(a)gregweber.info> On Sun, Dec 12, 2010 at 6:39 PM, Greg Weber <greg(a)gregweber.info> wrote: > Thanks for the feedback on the proposal. It is good to hear some criticism- > that means there are people using hamlet! So we have heard from current > users now- can we get feedback from those not using hamlet? Does the new > syntax tempt you into switching? If you were forced into a project with > hamlet, which syntax would you like best? Does anyone think that designers > would be more comfortable with the new syntax? > I would like to note another possible benefit to the proposal noted by a > commenter on Michael's blog- the removal of the '%' character means that > instead of signifying variable interpolation with '$' it could be done with > the '%', making the syntax uniform across hamlet, cassius, and julius. > I would like to be clear on the design goal of being closer to html. All > other things being equal, it is simply about avoiding a larger mental > overhead when switching between html and hamlet. The new syntax does not > mean we are "writing html" or have any "constraints" not already present in > hamlet. It simply means attributes use a space instead of a '!', and tags > begin with a '<' instead of a '%', and are separated with their inner text > by a '>' instead of a space. While the proposal discusses the possibility of > allowing things like closing tags, that would be optional if it were > implemented. > Reducing the mental "context switch" could be useful for existing hamlet > users that also works with html in other projects. But it is largely about > getting more users of hamlet, particularly when they start a new project. I > would not expect many projects to switch a project over, and closeness to > html when switching an existing project over doesn't matter much once > converters are available, and the larger the project, the more practical it > is to write a converter. I see the real practical use on a smaller scale- if > you want to copy and paste some html into your file, including html from a > more traditional templating language where a converter may not available. > Space-based attributes: > Are there any objection to the *concept* of the change to use a space with > attributes instead of a '!'?. This would actually make hamlet *more* similar > to HAML. > The difficulty in implementation is with determining the end of the > attribute portion of the tag. For '%body id=the-body' there would be > ambiguity as to whether the id started an attribute or inner text. Even > worse is an attribute without a value 'input type=checkbox checked'. One > technique is to assume it is an attribute if an '=' sign is present- > requiring escaping the '=' sign, and requiring a (possibly empty) value for > every attribute. HAML handles attributes by requiring opening and closing > symbole: '(attribute=name attribute2=name)', which looks nice, but I would > much rather have white space to begin attributes, and the closing character > is forced on you when there is no inner text. > Following my original proposal, the attributes could have a closing > character that is optional when there is no text. > %body id=the-body class=the-class>Inner Text > I could appreciate that this might look peculiar to someone when the tag > leads with a '%' instead of a '<' as in the original proposal. I think '&' > could be a lot more appealing and signifies 'and there is text', also > similar to how it signifies more parameters in a url. > %body id=the-body class=the-class&Inner Text > So I am still proposing the original proposal. If the original is not > accepted, or if we want more time to think about it or otherwise an > intermediate step is desired I would still propose using a space-based > attribute syntax. We could also consider the possibility of allowing both > the '%&' and the '<>' syntaxes now that they would be very similar. However, > I would strongly argue for using the html-compatible syntax. Those whose > senses are offended by a lone opening '<' can still add the '>' and justify > that it prepares them for adding inner text. I'm actually thinking that a good first step on this proposal is simply adding the <> syntax in addition to what we already have. For example: %foo!bar=baz This is something is equivalent to <foo bar=baz> This is something Without introducing any other changes. I originally did not like the idea of "two hamlets", but I'm beginning to warm up to it as an intermediate step. I'd even consider leaving both of them in there indefinitely, though I'm not sure that's the best idea. I very much would *not* like to implement a proposal such as % and whitespace attributes, eg: %foo bar=baz&This is something I don't like this for two reasons: 1) It's almost, but not quite, what we have right now. I'd much rather do a *big* change over to <> so that it's obvious that a change has occurred. 2) I don't want to start gobbling up more symbols. I also am not really interested in using the percent sign for variable interpolation in Hamlet/Cassius: dollar sign is well established for this in many languages, and I only grudgingly used the percent sign in Julius because of jQuery. If I'm not mistaken Greg, this means the part of your proposal which is being excluded by this proposal would be multi-line tags, is that correct? Michael > On Sun, Dec 12, 2010 at 3:00 AM, <web-devel-request(a)haskell.org> wrote: >> >> Send web-devel mailing list submissions to >> web-devel(a)haskell.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://www.haskell.org/mailman/listinfo/web-devel >> or, via email, send a message with subject or body 'help' to >> web-devel-request(a)haskell.org >> >> You can reach the person managing the list at >> web-devel-owner(a)haskell.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of web-devel digest..." >> >> >> Today's Topics: >> >> 1. Re: proposal for hamlet-like syntax that is more compatible >> with html (Michael Snoyman) >> 2. Re: proposal for hamlet-like syntax that is more compatible >> with html (Alexandros Salazar) >> 3. Re: proposal for hamlet-like syntax that is more compatible >> with html (Alexander Dunlap) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sat, 11 Dec 2010 17:48:48 +0200 >> From: Michael Snoyman <michael(a)snoyman.com> >> Subject: Re: [web-devel] proposal for hamlet-like syntax that is more >> compatible with html >> To: Simon Michael <simon(a)joyful.com> >> Cc: web-devel(a)haskell.org >> Message-ID: >> <AANLkTinumxoNV-efehgrVBUnoNUYvRB1ijC01aN6Pv=6(a)mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Alright, at this point I've only heard positive things about this >> syntax change. Does anyone want to volunteer to try and tackle this, >> or will this need to wait till I can get around to it? Fair warning: >> I'm likely to try to deal with the WAI + enumerator and xml-enumerator >> tasks first. If someone wants to take a crack at the Hamlet changes, >> I'll be happy to review things. >> >> Michael >> >> On Sat, Dec 11, 2010 at 2:38 AM, Simon Michael <simon(a)joyful.com> wrote: >> > I support this proposal's goal, and would be fine with rewriting my >> > templates. >> > >> > >> > _______________________________________________ >> > web-devel mailing list >> > web-devel(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/web-devel >> > >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Sat, 11 Dec 2010 11:17:37 -0500 >> From: Alexandros Salazar <nomothetis(a)gmail.com> >> Subject: Re: [web-devel] proposal for hamlet-like syntax that is more >> compatible with html >> To: web-devel(a)haskell.org >> Message-ID: >> <AANLkTikxJfPFOnD8Fzo9-bpH9g8Z6S6n8aCwB9+kvbAM(a)mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> My belated 2c (sorry, work has been keeping me away from things Yesod and >> Haskell): >> >> 1. The key reason I switched to Yesod was Hamlet. I'm very new to Haskell, >> and I wanted to try developing a webapp in it; when I looked at the >> various >> frameworks, my main question was "What will require me to learn the least >> new stuff, while still giving me a full Haskell-based development >> experience?" Yesod was the answer, because I was already familiar with >> Haml. >> So, it is one less thing a large swath of people need to learn when they >> decide to give Yesod a try. And at least in my case, it was a deciding >> factor. >> >> 2. I'm not convinced closeness to HTML is a design goal. My experience is >> again limited, but I wouldn't expect many people to switch existing >> projects >> to Yesod (or really, from any framework to any other); therefore, the idea >> that someone will have a bunch of HTML to be converted as simply as >> possible >> to whatever templating language we use seems remote. >> >> 3. Along the same lines, the reason for the existence of templating >> frameworks like Haml and Hamlet is precisely that people don't enjoy >> writing >> HTML: why would we constrain ourselves by similarity to something people >> have put large (and creative) amounts of effort into avoiding? I think it >> is >> unduly limiting. >> >> 4. I do believe there are some issues with Hamlet; in fact, the issues >> raised by Greg are exactly the issues I have. I don't see having a >> Yesod-specific templating language as the solution, unless this new syntax >> gives Yesod such a big productivity boost compared to using Hamlet that >> it's >> worth putting in the effort. >> >> In brief, I think Hamlet is 95% of the way there, and that Michael has >> done >> a great job with it. It seems easier to take it another 4% and get it to >> 99% >> than it would be to rewrite the syntax from scratch. I don't view HTML >> similarity as a bonus (or a malus, either way). Maintaining (and >> furthering) >> similarity with Haml seems worthier goal, given how many people use it, >> are >> familiar with it, and love it; it will ease adoption. >> >> I hope this all made sense, and that I didn't start an argument about bike >> shed colors... ;-) >> >> Alexandros >> >> >> >> On Sat, Dec 11, 2010 at 10:48 AM, Michael Snoyman >> <michael(a)snoyman.com>wrote: >> >> > Alright, at this point I've only heard positive things about this >> > syntax change. Does anyone want to volunteer to try and tackle this, >> > or will this need to wait till I can get around to it? Fair warning: >> > I'm likely to try to deal with the WAI + enumerator and xml-enumerator >> > tasks first. If someone wants to take a crack at the Hamlet changes, >> > I'll be happy to review things. >> > >> > Michael >> > >> > On Sat, Dec 11, 2010 at 2:38 AM, Simon Michael <simon(a)joyful.com> wrote: >> > > I support this proposal's goal, and would be fine with rewriting my >> > > templates. >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >>

3 3

Re: [web-devel] proposal for hamlet-like syntax that is more compatible
by Greg Weber 13 Dec '10

13 Dec '10

Are those in favor of HAML compatibility or not in favor of html brackets all in favor of HAML attribute syntax? instead of: %foo!bar=baz!class=more this: %foo(bar=baz class=more) I didn't like it because it is one extra character, but it is more readable and HAML compatible. We could also allow not having a closing parens (when there is no inner text). I am now beginning to appreciate why Michael chose the '!', but if we support 2 syntaxes going forward it would be nice if one as HAML compatible as possible.

1 0

Re: [web-devel] proposal for hamlet-like syntax that is more compatible with html
by Greg Weber 12 Dec '10

12 Dec '10

Thanks for the feedback on the proposal. It is good to hear some criticism- that means there are people using hamlet! So we have heard from current users now- can we get feedback from those not using hamlet? Does the new syntax tempt you into switching? If you were forced into a project with hamlet, which syntax would you like best? Does anyone think that designers would be more comfortable with the new syntax? I would like to note another possible benefit to the proposal noted by a commenter on Michael's blog- the removal of the '%' character means that instead of signifying variable interpolation with '$' it could be done with the '%', making the syntax uniform across hamlet, cassius, and julius. I would like to be clear on the design goal of being closer to html. All other things being equal, it is simply about avoiding a larger mental overhead when switching between html and hamlet. The new syntax does not mean we are "writing html" or have any "constraints" not already present in hamlet. It simply means attributes use a space instead of a '!', and tags begin with a '<' instead of a '%', and are separated with their inner text by a '>' instead of a space. While the proposal discusses the possibility of allowing things like closing tags, that would be optional if it were implemented. Reducing the mental "context switch" could be useful for existing hamlet users that also works with html in other projects. But it is largely about getting more users of hamlet, particularly when they start a new project. I would not expect many projects to switch a project over, and closeness to html when switching an existing project over doesn't matter much once converters are available, and the larger the project, the more practical it is to write a converter. I see the real practical use on a smaller scale- if you want to copy and paste some html into your file, including html from a more traditional templating language where a converter may not available. Space-based attributes: Are there any objection to the *concept* of the change to use a space with attributes instead of a '!'?. This would actually make hamlet *more* similar to HAML. The difficulty in implementation is with determining the end of the attribute portion of the tag. For '%body id=the-body' there would be ambiguity as to whether the id started an attribute or inner text. Even worse is an attribute without a value 'input type=checkbox checked'. One technique is to assume it is an attribute if an '=' sign is present- requiring escaping the '=' sign, and requiring a (possibly empty) value for every attribute. HAML handles attributes by requiring opening and closing symbole: '(attribute=name attribute2=name)', which looks nice, but I would much rather have white space to begin attributes, and the closing character is forced on you when there is no inner text. Following my original proposal, the attributes could have a closing character that is optional when there is no text. %body id=the-body class=the-class>Inner Text I could appreciate that this might look peculiar to someone when the tag leads with a '%' instead of a '<' as in the original proposal. I think '&' could be a lot more appealing and signifies 'and there is text', also similar to how it signifies more parameters in a url. %body id=the-body class=the-class&Inner Text So I am still proposing the original proposal. If the original is not accepted, or if we want more time to think about it or otherwise an intermediate step is desired I would still propose using a space-based attribute syntax. We could also consider the possibility of allowing both the '%&' and the '<>' syntaxes now that they would be very similar. However, I would strongly argue for using the html-compatible syntax. Those whose senses are offended by a lone opening '<' can still add the '>' and justify that it prepares them for adding inner text. On Sun, Dec 12, 2010 at 3:00 AM, <web-devel-request(a)haskell.org> wrote: > Send web-devel mailing list submissions to > web-devel(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/web-devel > or, via email, send a message with subject or body 'help' to > web-devel-request(a)haskell.org > > You can reach the person managing the list at > web-devel-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of web-devel digest..." > > > Today's Topics: > > 1. Re: proposal for hamlet-like syntax that is more compatible > with html (Michael Snoyman) > 2. Re: proposal for hamlet-like syntax that is more compatible > with html (Alexandros Salazar) > 3. Re: proposal for hamlet-like syntax that is more compatible > with html (Alexander Dunlap) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 11 Dec 2010 17:48:48 +0200 > From: Michael Snoyman <michael(a)snoyman.com> > Subject: Re: [web-devel] proposal for hamlet-like syntax that is more > compatible with html > To: Simon Michael <simon(a)joyful.com> > Cc: web-devel(a)haskell.org > Message-ID: > <AANLkTinumxoNV-efehgrVBUnoNUYvRB1ijC01aN6Pv=6(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Alright, at this point I've only heard positive things about this > syntax change. Does anyone want to volunteer to try and tackle this, > or will this need to wait till I can get around to it? Fair warning: > I'm likely to try to deal with the WAI + enumerator and xml-enumerator > tasks first. If someone wants to take a crack at the Hamlet changes, > I'll be happy to review things. > > Michael > > On Sat, Dec 11, 2010 at 2:38 AM, Simon Michael <simon(a)joyful.com> wrote: > > I support this proposal's goal, and would be fine with rewriting my > > templates. > > > > > > _______________________________________________ > > web-devel mailing list > > web-devel(a)haskell.org > > http://www.haskell.org/mailman/listinfo/web-devel > > > > > > ------------------------------ > > Message: 2 > Date: Sat, 11 Dec 2010 11:17:37 -0500 > From: Alexandros Salazar <nomothetis(a)gmail.com> > Subject: Re: [web-devel] proposal for hamlet-like syntax that is more > compatible with html > To: web-devel(a)haskell.org > Message-ID: > <AANLkTikxJfPFOnD8Fzo9-bpH9g8Z6S6n8aCwB9+kvbAM(a)mail.gmail.com<AANLkTikxJfPFOnD8Fzo9-bpH9g8Z6S6n8aCwB9%2BkvbAM(a)mail.gmail.com> > > > Content-Type: text/plain; charset="utf-8" > > My belated 2c (sorry, work has been keeping me away from things Yesod and > Haskell): > > 1. The key reason I switched to Yesod was Hamlet. I'm very new to Haskell, > and I wanted to try developing a webapp in it; when I looked at the various > frameworks, my main question was "What will require me to learn the least > new stuff, while still giving me a full Haskell-based development > experience?" Yesod was the answer, because I was already familiar with > Haml. > So, it is one less thing a large swath of people need to learn when they > decide to give Yesod a try. And at least in my case, it was a deciding > factor. > > 2. I'm not convinced closeness to HTML is a design goal. My experience is > again limited, but I wouldn't expect many people to switch existing > projects > to Yesod (or really, from any framework to any other); therefore, the idea > that someone will have a bunch of HTML to be converted as simply as > possible > to whatever templating language we use seems remote. > > 3. Along the same lines, the reason for the existence of templating > frameworks like Haml and Hamlet is precisely that people don't enjoy > writing > HTML: why would we constrain ourselves by similarity to something people > have put large (and creative) amounts of effort into avoiding? I think it > is > unduly limiting. > > 4. I do believe there are some issues with Hamlet; in fact, the issues > raised by Greg are exactly the issues I have. I don't see having a > Yesod-specific templating language as the solution, unless this new syntax > gives Yesod such a big productivity boost compared to using Hamlet that > it's > worth putting in the effort. > > In brief, I think Hamlet is 95% of the way there, and that Michael has done > a great job with it. It seems easier to take it another 4% and get it to > 99% > than it would be to rewrite the syntax from scratch. I don't view HTML > similarity as a bonus (or a malus, either way). Maintaining (and > furthering) > similarity with Haml seems worthier goal, given how many people use it, are > familiar with it, and love it; it will ease adoption. > > I hope this all made sense, and that I didn't start an argument about bike > shed colors... ;-) > > Alexandros > > > > On Sat, Dec 11, 2010 at 10:48 AM, Michael Snoyman <michael(a)snoyman.com > >wrote: > > > Alright, at this point I've only heard positive things about this > > syntax change. Does anyone want to volunteer to try and tackle this, > > or will this need to wait till I can get around to it? Fair warning: > > I'm likely to try to deal with the WAI + enumerator and xml-enumerator > > tasks first. If someone wants to take a crack at the Hamlet changes, > > I'll be happy to review things. > > > > Michael > > > > On Sat, Dec 11, 2010 at 2:38 AM, Simon Michael <simon(a)joyful.com> wrote: > > > I support this proposal's goal, and would be fine with rewriting my > > > templates. > > > > > > > > > _______________________________________________ > > > 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 > > >

3 2

proposal for hamlet-like syntax that is more compatible with html
by Greg Weber 12 Dec '10

12 Dec '10

It is clear from my experience working with html that hamlet has the right idea. The one time I worked on a HAML (the original hamlet, for Ruby) project professionally it was wonderful. However, the actual hamlet syntax could be implemented more nicely and that there is an opportunity for the syntax to be more similar to html. In particular, I would much rather have white space (and quotes where needed) than exclamation marks. Here is one possible alternative: https://github.com/stonean/slim With this style you end up with something like this: form action=url = text #id.class But a more practical syntax could allow compatibility with existing html- this has always been the main weakness of these newer systems. As I said, I have only worked on 1 HAML project, but have used standard templates for everything else. Even after a proper converter is built, the different syntax is a point of pain. Compatibility would also help remove part of the criticism that Yesod is off in its own little world. Instead of '%body' why not '<body'. A closing angle bracket is required to begin text on the same line for the tag- '<body>text'. The alternative of just having a space '<body text' would be ambiguous with respect to attributes that have no value and be less html compatible. The 'attribute="name"' style would be kept although the quotes are optional- '<body class=page1', or '<body class="page1">' would also be acceptable for compatibility and closing over white space. Of course, the id and class shortcuts would be available- '<body.page1' If the previous tag has no inner text on its line and the next indented line does not start with a '#', '<', or '.' then it is the inner text of the previous tag. <body.page1 text #id.class And the advantage is that it looks much more similar to html, and has easier compatibility. Given <body class="page1"> text <div id="id" class="class" title="div">div text</div> </body> This could actually be parsed as valid if the indentation was consistent. However, at the point one is correcting indentation one might as well remove closing tags. The only thing that needs be done for the html to be parsed is consistent indentation and removal of closing tags. For the div above it might be possible to even keep the closing tag. If that were done it might be possible to allowing multiple tags on one line for the sake of easier html importing. <body class="page1"> text <div id="id" class="class" title="div"><h2>title</h2><p>div text</p></div> </body> But the general idea is that html can be copied into a Hamlet template and quickly converted into valid Hamlet. Then it is up to the developer whether to spend the time to compact things even more once the template can be parsed. <body.page1 text #id.class title=div <h2>title <p>div text That's not so scary, is it? One possible alternative syntax would be for a div with a class or id to still require the opening angle bracket- '<#id.class'. This might be more visually appealing when text is placed on the same line: '<#id.class title=div>text' instead of '#id.class title=div>text'. Perhaps both could be allowed. Michael Snoyman is "intrigued" by this proposal and pointed out that because '<' is not used in Hamlet it would be possible to maintain a backwards compatible mode. However, we both don't want to fracture the community- this is a proposal to permantenly improve things and then deprecate the previous syntax, providing a converter to upgrade. I would appreciate feedback from some haskellers. Are there any limitations are drawbacks to such a syntax, or is it just different? Does this appeal to you more hamlet? Will this make a convert out of anybody who runs away screaming when they see a hamlet template? Greg Weber

6 5

ANN: Digestive functors 0.0.2.0
by Jasper Van der Jeugt 09 Dec '10

09 Dec '10

Hello all, I'm very glad to announce the 0.0.2.0 release of the digestive functors library. The library provides a general API to input consumption, and is an upgrade of formlets. I've written an announcing blogpost and tutorial with more information here: http://jaspervdj.be/posts/2010-12-09-digestive-functors-0.0.2.html You can get it on hackage here: http://hackage.haskell.org/package/digestive-functors As always, all feedback is welcome. Kindest regards, Jasper Van der Jeugt

1 0

Yesod server logs
by Alexandros Salazar 06 Dec '10

06 Dec '10

Hi, I'm wondering if there is a way to log the server output for Yesod. I am currently getting an error of "Failed to load resource: the server responded with a status of 500 (Internal Server Error)" and I have no idea what is causing the issue; I don't know if the server knows, but I'd like to find out. Any help would be appreciated. Thanks! Alexandros

3 5

Emacs modes for hamlet/cassius
by Aur Saraf 03 Dec '10

03 Dec '10

Hi, Is there any emacs + yesod user here with any emacs support for cassius/hamlet? Hopefully good modes, but even some settings for an existing mode would be appreciated. Thanks, Aur

1 0

[Yesod] When POST and create new resource
by いとうかつとし 29 Nov '10

29 Nov '10

Hi I have a question. I think that, when a server receive POST request and create new resource(and URI), the server response is status 201, isn't it? (I'm not really sure about this idea.) On Yesod, How we write to make status201 response?

5 7

ANNOUNCE: yesod-continuations
by Matt Brown 27 Nov '10

27 Nov '10

Hello all, I pushed a new package yesod-continuations to hackage. It allows you to register a handler for one time use (by the session that generated it) at a unique URL. I wrote it as an alternative to subsites for writing yesod widgets with "internal urls" (ajax widgets, for example). A demo (testcont.hs) is included in the source, and the master and continuation branches of my yesod-tailwidget repo compare the two approaches. Feedback is welcome. regards, -matt Hackage: http://hackage.haskell.org/package/yesod-continuations-0.1 GitHub: https://github.com/softmechanics/yesod-continuations yesod-tailwidget GitHub: https://github.com/softmechanics/yesod-tailwidget

1 0

Yesod Form
by Dmitry Olshansky 25 Nov '10

25 Nov '10

Hello all, can I handle a form with more than one button in Yesod? In this case pair (button_name, button_value) is sent to the server on submit. Can I get it in some way? Best regards, Dmitry

2 3