- web-devel - Haskell.org

Yesod User Survey
by Michael Snoyman 21 Dec '10

21 Dec '10

Hi all, I wanted to let you know that I've put up a Yesod user survey[1]. The goal is to get some good feedback on what the Yesod team should be focusing on to make the framework (and all related libraries) more useful. If you're using Yesod, related packages, or are just interested in the whole thing, please take the time to fill out the survey. I've put up basically the same information, plus a little status update on Yesod 0.7, in a blog post[2]. Thanks, Michael [1] https://spreadsheets.google.com/viewform?formkey=dDRhcFVCRVdjbXZuNXJGVUItb3… [2] http://docs.yesodweb.com/blog/yesod-user-survey/

1 0

Re: [web-devel] [Yesod][Persist] Like keyword
by Greg Weber 21 Dec '10

21 Dec '10

mongoDB does not have LIKE. But it has regular expressions, so LIKE is easy to implement. I doubt Redis has anything here. A true key-value store like Redis already doesn't make much sense with the filtering 'Where' queries. I think of Persistent not as a key-value friendly store, but as a noSQL friendly interface (no joins) that something like MongoDB fits in well. The other think to think about is creating better capabilities for allowing users to use arbitrary SQL (or mongo queries) with Persistent.

2 1

Re: [web-devel] [Yesod] Is there a api which get yesod version?
by Michael Snoyman 21 Dec '10

21 Dec '10

Thanks to everyone for input on this, I was completely unaware of Paths_* being provided by cabal. I've just pushed a yesodVersion function to the ver0.7 branch on Git. For the record, you *do* need to include the Paths_* module in other-modules in order to make your code usable. Michael On Tue, Dec 21, 2010 at 2:42 PM, Simon Meier <iridcode(a)gmail.com> wrote: > > > 2010/12/21 Felipe Almeida Lessa <felipe.lessa(a)gmail.com> >> >> 2010/12/21 Michael Snoyman <michael(a)snoyman.com>: >> > Do you know of any prior art that does this? Having a package import >> > files generated by cabal seems like it could cause problems. >> >> Although Cabal's documentation only mentions 'getDataFileName' [1], >> the API states that the Paths module should "enable [the packages] to >> find their version number" [2]. So that's the intended use, even if >> not very well documented. Just remember to put the Paths in >> 'other-modules' [1]. > > I'm not sure, if it should be put in 'other-modules' as the > your_project_paths.hs is an autogenerated file, which you don't want to ship > with your source. I'd rather go for exporting the yesod version via its own > API and use the paths file to implement that functionality. One thing, I > always found useful is to have a directory > interactive-only-src/ > containing a copy of the autogenerated paths file as in > interactive-only-src/your_project_paths.hs > together with the .ghci file containing a line > :set -iinteractive-only-src > This way you GHCi works as intended and the paths file is autogenerated and > compiled in upon install. > > cheers, > Simon >> >> [1] >> http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.h… >> [2] >> http://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distributio… >> >> Cheers! =) >> >> -- >> Felipe. >> >> _______________________________________________ >> web-devel mailing list >> web-devel(a)haskell.org >> http://www.haskell.org/mailman/listinfo/web-devel > >

1 0

[Yesod] Is there a api which get yesod version?
by いとうかつとし 21 Dec '10

21 Dec '10

hi, i'd like to display like as "powered by Yesod ver 0.6.7" on footer of my application. Is there an api?

5 5

[Yesod] getBy404.
by いとうかつとし 20 Dec '10

20 Dec '10

I'd like to support getBy404 as like as get404 on yesod framework. getBy404 ukey = do mres <- getBy ukey case mres of Nothing -> lift notFound Just res -> return res for example, on wiki site, the resource url include wikiname as key(String) not id (Int). In this situation, getBy404 are frequently encountered. How about this?

3 4

[Yesod] setUltDest' lost query param, it's right thing?
by いとうかつとし 20 Dec '10

20 Dec '10

setUltDest' which used in redirectLogin(which is called from requireAuth) set session reqGetParams, but not postParams. This means that , if there are a code as below, posted parameters are lost, aren't these? postFooR :: Handler RepHtml postFooR = do (uid,_) <- requireAuth (x, y) <- uncurry (liftM2 (,)) (lookupPostParam "x", lookupPostParam "y") .... defaultLayout $ do .... ....

2 1

Interpolation character in Julius
by Michael Snoyman 20 Dec '10

20 Dec '10

Hamlet, Cassius and (currently) Julius all use a consistent set of characters for interpolation. The dollar sign ($) is for plain scalars, the at sign (@) is for URLs and the caret (^) is for embedding other templates (mixins in the case of Cassius). I like this consistency. Unfortunately, in the case of Julius, the dollar sign is a suboptimal character to use since jQuery uses is so extensively. Currently, to write some simple jQuery Javascript such as: $("h1").hide() you have to use a double dollar sign to achieve escaping, namely: $$("h1").hide() So the questions to the list are: * Is it worth trading consistency for a better choice of interpolation character? * If so, what would be a more optimal interpolation character? I think percent sign (%) might be acceptable. Interpolation is not as important in Julius as it is in Hamlet, so I'm beginning to lean towards replacing the character. Michael

2 4

Open for testing: new Hamlet syntax
by Michael Snoyman 19 Dec '10

19 Dec '10

Hey all, I've just pushed the first commit that includes support for the angle-bracket syntax in Hamlet. Anyone who's interested, please take a look at the code[1] and try to figure out what doesn't work yet. I'm sure there are a lot of corner cases I have not yet taken into account, so if you find something that doesn't produce the output you expected, please let me know so I can add a test case for it and try to get it fixed. (Yes, I code Hamlet with TDD.) On a related note for those interested, I've started work on a lot of new major versions for packages, including wai, wai-extra, persistent and yesod. One of the things I'm considering for this release of Yesod (0.7, not a 1.0 yet) is to move some of the functionality into separate packages. In particular, I think forms, crud and json will all be put in their own packages. The only change to persistent is migrating from MonadInvertIO to MonadPeelIO, which is a much more well designed approach. wai will most likely be seeing a major change in how the underlying mechanism works to make it more efficient (based on blaze-builder), more standard (based on enumerator) and more generic. This last point might make the interface more confusing, but I think it is worth it overall. The new version of Yesod will be based on this version of WAI, and I plan to simultaneously release new versions of related packages, like wai-handler-fastcgi or yesod-auth. Also, last call on new Yesod web page design. If no one volunteers, I'm just going to grab the standard Haskell color scheme and get to work on it myself. Michael [1] https://github.com/snoyberg/hamlet

2 2

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

13 Dec '10

As per Michael's question of multi-line attributes- I find that is very much the exception and not the rule. I haven't given much thought to it other than to assume we can come up with a way to allow multi-line attributes. if nothing else we could have a line-continuation marker- a space would end the attribute and then a character of our choosing that is not valid for an attribute name would indicate a continuation to the next line.

1 0

Re: [web-devel] proposal for hamlet-like syntax that is more compatible with html
by Michael Snoyman 13 Dec '10

13 Dec '10

On Sun, Dec 12, 2010 at 9:14 PM, Greg Weber <greg(a)gregweber.info> wrote: > what are multi-line tags? does that mean the attributes are on multiple > lines? If you mean inner text, I don't see anything stopping inner text from > the second line. I meant attributes on multiple lines, sorry for the ambiguity. > All well-thought points. Given the resistance to change I am also warming to > multiple versions. What I was trying to do was get rid of '!' in any > version- I really don't like that, especially when there are multiple > attributes. It is fine when there is one attribute, but otherwise I find it > hard to read compared to white space. And frankly, I don't think have a %! version and a <> is horribly confusing. I personally wouldn't want to use both in the same template, but I think it could work at well overall. > For Julius, perhaps '$(' - with an opening bracket could be jQuery. > Prototype has $$, and $A, but again, any real world use should have an > opening parens. There is one other use of having it as a function argument, > but > that can be decipehred also- function($,a){} - in this case there will be > only white space and a comma after the dollar. I don't like it because: * It violates principle of least surprise * It doesn't allow things like $.getJSON Michael > On Sun, Dec 12, 2010 at 8:54 AM, Michael Snoyman <michael(a)snoyman.com> > wrote: >> >> 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 >> >> > >> >>

1 0