- web-devel - Haskell.org

wish to create a dropdown menu via yesod
by Michael Litchard 01 Jun '11

01 Jun '11

Could someone give me a code snippet to create a drop down like this: http://www.w3schools.com/html/tryit.asp?filename=tryhtml_select2 thanks

3 6

Re: [web-devel] Kick-off discussion: Yesod 0.9
by Michael Snoyman 01 Jun '11

01 Jun '11

On Wed, Jun 1, 2011 at 7:02 PM, Justin Greene <nephesh.chifire(a)gmail.com> wrote: >> Right now, you can apply whatever validation you want to an individual >> fields and display the error messages inline. For complex scenarios, >> I'm not quite certain what an interface (both programming interface >> and UI) would look like for assigning these error messages inline. >> Short of that, it seems outside the scope of the form package itself >> to validate such interactions. For example, you could always write >> code along the lines of: >> >> ((res, form), enctype) <- runFormPost ... >> case res of >> FormSuccess x -> >> case complexTest x of >> Left e -> showFormWithErrMsg form e >> Right y -> onSuccess y >> _ -> showFormWithoutErrMsg form > > My only comment about this is that it creates a bad user experience. If my > form type binding is not successful on all fields then this complex > validation scenario will not fire. This makes it so the user has to get > past one set of error messages, and then move on to the next set. Ideally > they would receive all error messages at once that are possible to validate > at the time. While it may not be easy in haskell to accomplish this, it's > definitely something that needs to be considered imo. > > An example form: > CheckBox > FirstName > Date of Birth > > If a user selects the checkbox then the first name is now required. > However, they entered an incorrectly formatted date of birth. We have > enough information to fire to the complex validator in this scenario at the > same time as showing an error about an improper date for the date of birth > field. The above example wouldn't do this though, it would first show an > error about the date of birth being invalid, and then after that is fixed it > would show the error about the first name being required. > > I realize haskell makes this scenario challenging, so it may not be worth > your time to optimize for it, but I think any advanced forms framework > should consider it. > > I would love to help design this api, but my hobby time is going to be all > used up for a long while (trying to bootstrap a startup in my spare time). > I will say that I think template haskell is probably the only way to > actually fulfill these types of requirements in haskell (though I could > easily be wrong about that). I think the solution here is to create a combined field for checkbox + name field. In the Applicative case, this would constrain you to having both widgets display in the same table cell/div, but I think this is acceptable: Applicatives are meant for "standard" layouts. If you want something more custom, you'll end up with a Monadic form providing a "FormResult (Bool, Text)". Obviously, the library isn't going to do *exactly* what you're looking for in every case (unless you're in the fortunate position like me of having written the library), but I think there's enough power available to cover even complicated cases in a safe way. I think TH isn't necessary here, though its usage may allow for significantly more concise definitions. Michael

1 0

Re: [web-devel] Kick-off discussion: Yesod 0.9
by Greg Weber 01 Jun '11

01 Jun '11

The scenario I am considering is if you accidentally leave a form field in the form/view model that you removed from your view and then use techniques to automatically assign data back to the model. Obviously I know little of the F# frameworks :) On Wed, Jun 1, 2011 at 9:14 AM, Justin Greene <nephesh.chifire(a)gmail.com>wrote: > Hi Greg, > > > From what I can tell, the form/view model is roughly the same as building >> up an applicative form. If you build a custom form, you have to declare a >> field both in your form/view model and in your view, which is the kind of >> insecure duplication we would like to avoid when possible. >> > > I am unclear as to what you mean by "insecure". You do have to specify > where you want your field to render, but there is no chance of someone > maliciously adding fields to your form, or inserting data into fields that > you do not specify. > >

1 0

Kick-off discussion: Yesod 0.9
by Michael Snoyman 01 Jun '11

01 Jun '11

Hi all, It's been about a month since the 0.8 release of Yesod. In the release announcement[1], we laid out some goals. Let's take a chance to analyze where we're at: * Documentation: Still improving as always. In particular, the new Yesod site is making it much easier for me to write new content (I have a few things on my local system that can finally go up). * Static file caching headers: Implemented by Greg Weber. We'll likely be making some API changes to handle embedded files, though that discussion deserves its own blog post. * Other template types: For Hamlet 0.9, we're going to be splitting Julius/Coffeescript into their own package, and juggling the type signature for Coffeescript a bit. At that point, it should be straightforward to embed Coffeescript directly into a Yesod app, just like Julius is today. * Something like require.js: This is something we haven't started on yet. I'll likely start looking into it this week. Additionally, I know that a lot of my sites (jQuery powered) have numerous onload calls per page; I think we can try to make that more efficient as well. I would especially like people's input on this point. * i18n: The solution is written, and I'm using it in production. At this point, I'd call it beta quality, and I'd appreciate input. * Forms package: It's been rewritten, but hasn't really had much input from others. Now's the time to speak up if you have any opinions on it. The code is available on Hackage. * Embedded objects in MongoDB: No work done yet. * Performance improvements: Nothing in particular. If you have any examples of Yesod performing badly, please let us know. The goal is for Yesod 0.9 to be feature complete, and for 1.0 to be a fairly stable API. From the list above, my two priorities are better Javascript loading (require.js) and static file serving. However, there's one other major issue we need to address: the devel server. Unfortunately, it doesn't work very well at all right now. Thankfully, "yesod build" *does* work very well, and for my development I've fallen back to simply "yesod build && ./dist/build/myapp/myapp" on the command line. My guess is that we're 90% of the way there on "yesod devel". This is a project that isn't tightly bound to the rest of the API work, and would be very approachable for someone trying to get started on Yesod development. If you're interested in helping out here, please let me know. I have no specific timeframe in mind for Yesod 0.9. As it stands now, it looks like the 0.9 release will involve almost no API breakage, which is a very good sign. But if you have any ideas you'd like to contribute, I'd recommend getting them in in the next week or two. Michael [1] http://www.yesodweb.com/blog/2011/4/announcing-yesod-0-8

5 11

Re: [web-devel] Kick-off discussion: Yesod 0.9
by Michael Snoyman 01 Jun '11

01 Jun '11

On Wed, Jun 1, 2011 at 9:10 AM, Blake Rain <blake.rain(a)massivetactical.com> wrote: > Hey guys, > > Some random thoughts while I have some time :) > > > On Mon, 2011-05-30 at 23:41 +0300, Michael Snoyman wrote: >> Hi all, >> >> It's been about a month since the 0.8 release of Yesod. In the release >> announcement[1], we laid out some goals. Let's take a chance to >> analyze where we're at: >> >> * Documentation: Still improving as always. In particular, the new >> Yesod site is making it much easier for me to write new content (I >> have a few things on my local system that can finally go up). > > Excellent :) > I also very much like the wiki. Perhaps a cook-book section? Sounds good. Personally, I'm going to be putting my examples up as blog posts, but I strongly encourage people to add their own examples as well, and if someone wants to start a world-editable topic linking those examples together, I'd be happy to give it a prominent link. >> * Static file caching headers: Implemented by Greg Weber. We'll likely >> be making some API changes to handle embedded files, though that >> discussion deserves its own blog post. > > This would be extremely useful: We currently serve static files > from a different domain using a different server (NGinX I think). If > Warp was to handle this out of the box then a measure of complexity > would be removed from our server configuration. Which is always of > benefit. Even though Warp will be able to handle this, there would likely be two reasons to stick with your current setup: 1) Nginx on a separate domain won't involve cookie overhead. 2) Nginx will likely be a bit faster than Warp for static files. The first issue, however, could be mitigated by using virtual hosting within your Warp setup. And I'm not sure how significant the performance difference is between nginx and warp. > Aside: I do need to have a chat with you (Michael et al) at some point > about deployment strategies and WAI applications when we (Massive) get > onto the next two projects (December mostly likely, unless I find some > more staff). I'm feeling much more confident about this after the deployment of the new Yesod site. Setting up EC2 couldn't have been simpler: start an instance, install nginx and postgresql, configure upstart for nginx and the Yesod app, and copy the executable. I think this process could easily be turned into a script, and customized for different persistent backends. >> * Other template types: For Hamlet 0.9, we're going to be splitting >> Julius/Coffeescript into their own package, and juggling the type >> signature for Coffeescript a bit. At that point, it should be >> straightforward to embed Coffeescript directly into a Yesod app, just >> like Julius is today. > > Is CoffeeScript really any better than JavaScript? Are any Haskellers > having any success using it? Would the CoffeeScript compiler still need > to be installed on the server to be invoked by the Yesod application? Or > would it be done at compile time? The CoffeeScript compiler needs to be available on the server at runtime. I personally don't use it at all. [snip] >> * Forms package: It's been rewritten, but hasn't really had much input >> from others. Now's the time to speak up if you have any opinions on >> it. The code is available on Hackage. > > I am hoping to take a look at the new forms package shortly. I had to > write all our form processing manually due to various complexities that > could not be covered by yesod-forms. Would a description of these be > useful? Yes, incredibly useful. Currently, yesod-forms is scratching all my itches, so I need to know what is missing to improve it. >> * Embedded objects in MongoDB: No work done yet. > > Would this not make persistent more complex? Is it necessary to do so? I'm hoping not. The goal is to keep persistent the same. > We migrated away from persistent and PostgreSQL to MongoDB on a > suggestion by Greg Weber (we felt acid-state is not yet mature enough > for our purposes). We used an in-house abstraction on top of the MongoDB > Haskell driver to allow easier marshalling, object embedding, > persistent-like keys and such. > > Unfortunately, this did mean we had to fight a lot with some > deficiencies we found in Data.BSON. Also we had to refactor almost the > entire site, which was quite good fun :) > >> >> * Performance improvements: Nothing in particular. If you have any >> examples of Yesod performing badly, please let us know. > > I've got examples of it performing extremely well ;) Those are good too. >> >> The goal is for Yesod 0.9 to be feature complete, and for 1.0 to be a >> fairly stable API. From the list above, my two priorities are better >> Javascript loading (require.js) and static file serving. However, >> there's one other major issue we need to address: the devel server. >> Unfortunately, it doesn't work very well at all right now. Thankfully, >> "yesod build" *does* work very well, and for my development I've >> fallen back to simply "yesod build && ./dist/build/myapp/myapp" on the >> command line. My guess is that we're 90% of the way there on "yesod >> devel". This is a project that isn't tightly bound to the rest of the >> API work, and would be very approachable for someone trying to get >> started on Yesod development. If you're interested in helping out >> here, please let me know. > > It is a bit broken. Our current (and first) project using Yesod has 85 > modules, 93 hamlet files, etc... The devel server just takes too long > and sometimes dies. It also consumes an inordinate amount of memory (2-3 > Gb). I'm guessing this was with "wai-handler-devel", right? yesod 0.8 introduced a *new* broken devel server, "yesod devel" :). But its problem shouldn't be memory usage. If so, I'd like to hear more. > At the moment I use GHCi, a typical session being: > > 1. Make some changes > 2. `touch` .hs file if Hamlet file is modified > 3. :reload > 4. main > 5. Test in browser (or whatever) > 6. Ctrl+C > 7. goto 1 > > I've been working this way for some time now, and it actually seems to > be working very well. Our designer gets upset -- but he always does :P > > Only thing I might do is reduce `settingsTimeout` in the argument to > `runSettings` in Warp to something more useful for debugging (like 5). > >> >> I have no specific timeframe in mind for Yesod 0.9. As it stands now, >> it looks like the 0.9 release will involve almost no API breakage, >> which is a very good sign. But if you have any ideas you'd like to >> contribute, I'd recommend getting them in in the next week or two. > > > Ultimately, I'd prefer Yesod was correct, rather than on time :) > > In spite of any issues Yesod has, We are using it in a production > environment very successfully. Our client and their investor(s) are very > satisfied with the project, and it will be released to the public > shortly. > > This weekend I tested scalability, and ran the beta application on a > cluster to test load-balancing, fail-over and so on (mostly whilst > getting used to MongoDB). It performed beautifully. > > If anything, I'd prefer work was concentrated on the forms package to > make it magically cater for all my needs ;) But I suppose I should > define those needs first. > > Again, many thanks for all your hard work! > > - B. > > >> >> Michael >> >> [1] http://www.yesodweb.com/blog/2011/4/announcing-yesod-0-8 >> >> _______________________________________________ >> web-devel mailing list >> web-devel(a)haskell.org >> http://www.haskell.org/mailman/listinfo/web-devel > > >

1 0

Fwd: Issue with getAuthId never getting executed
by Mathew de Detrich 01 Jun '11

01 Jun '11

I seem to be having an issue where getAuthId (when being instantiated under YesodAuth) is never being executed on my site, which basically prevents the necessary data from being inserted into the database and the AuthId being set up (or the Auth system working in general, at all). I'm not sure if this is an issue with Haskell's lazy evaluation, browsing through the source code I note that getAuthId is called by setCreds, which is inturn called when you instantiate an authentication plugin (in my case I am using facebook)). I am using a simple liftIO$ putStrLn "getAuthId" inside the getAuthId to figure out if the function is being called (and I never manage to get Haskell to execute it). Furthermore nothing is being entered into my database (which would happen if its called). Originally I used to think this was due to Haskell's laziness or black magic, (I was initiating maybeAuth but never using the variable), I then forced evaluation of maybeAuth, obviously with no results (and maybeAuth always returns Nothing). The actual logging into facebook and redirecting works fine. I am using yesod-auth-0.42 with authenticate 0.9.0.1 and yesod 0.8.1 Also on another note (since I am unable to test it right now), if I wish to get data from facebook using the graph API (in my case I am doing this inside getAuthId as well), something like this is done? let [(_,at)] = credsExtra creds fbname <- liftIO $ getTextFBData at "name" where getTextFBData is defined as textFromJSON :: Value -> T.Text textFromJSON v = case (fromJSON v) of Success a -> a Error b -> T.pack b getTextFBData :: T.Text -> T.Text -> IO (T.Text) getTextFBData at rq = do let at' = AccessToken at rqeither <- liftIO $ getGraphData at' rq return (either (\x-> "invalid request from FB") textFromJSON rqeither)

1 0

Re: [web-devel] DTD types
by John Millikin 31 May '11

31 May '11

On Tue, May 31, 2011 at 00:30, Yitzchak Gale <gale(a)sefer.org> wrote: >>> For example, I couldn't use name, because for DTD namespaces >>> *are* significant so they need a different Eq instance. I ended up >>> just using Text." > >> I don't understand what this means; the xml-types Eq instance >> for Name compares both the namespace and local name > > Ah, OK. I misunderstood the docs - it says that the "prefix" > is not used in the Eq instance, so I took that to mean > that namespaces prefixes were not used. Now that I look > more carefully at the code itself, I see that is not true. > > But then what is a "prefix"? The IsString instance always sets > the prefix to Nothing. I've scoured the XML spec and not > found anything it could possibly represent. What have I > missed? Lets say you have a document like this: <foo:doc xmlns:foo="http://my/namespace/here">bar</foo:doc> The name of the element will have the components: prefix = "foo" namespace = "http://my/namespace/here" local name = "doc" The prefix is not semantically important; all names are identified by the (namespace, local name) pair. Thus, comparing two names ignores the prefix. But it's still useful to keep around when 1) working with poorly-written parsers (eg, many XMPP servers) or 2) performing minimal-diff changes on a complex document. > Another point I noticed when looking at the IsString instance > for Name: it can introduce crashes into a program if someone > accidentally puts a '{' at the beginning of a Name string. > Everywhere else, your code is safe; even if someone inserts > invalid XML, you leave it up to the application to decide > how much to validate and what to do if validation fails. > > So could you please change this to pass the string through > as a plain Name without a namespace if Clark notation > parsing fails? Thanks. The IsString instance is intended for overloaded string literals -- that is, the source code would look something like this: ------------------ elem = Element "{http://my/namespace/here}doc" [] [] ------------------ It's not intended for parsing arbitrary input, as it performs no validation of its input (aside from trivial checks for Clark brackets). If you are concerned that a developer may cause exceptions by writing incorrect code, it would be better to use the Name constructor directly. > I noticed that you did not send your response to the list. > Do you mind if I forward a copy of this response > to the web-devel list? Oops, didn't realize there were two separate email threads. Here's the text of my earlier email, for future readers: ---------------- On Mon, May 30, 2011 at 11:13, John Millikin <jmillikin(a)gmail.com> wrote: > I agree that it makes more sense as a separate package -- DTDs are > sort of a layer on top of XML, and there's lots of people who want to > work with one without worrying about the other. I don't mind merging > them if you want, but separate seems better. > >> For example, I couldn't use name, because for DTD namespaces *are* significant so they >> need a different Eq instance. I ended up just using Text." > > I don't understand what this means; the xml-types Eq instance for Name > compares both the namespace and local name: > > -------------------------------- > instance Eq Name where > (==) = (==) `on` (\x -> (nameNamespace x, nameLocalName x)) > -------------------------------- > > As to the package itself, I have only one suggestion: can you add a > constructor to DTDComponent for processing instructions? If I'm > reading the XML spec correctly, these can occur anywhere within a DTD. > > Thank you very much for the good work! ----------------

1 0

Re: [web-devel] Kick-off discussion: Yesod 0.9
by Aristid Breitkreuz 31 May '11

31 May '11

Am 31.05.2011 09:12 schrieb "Michael Snoyman" <michael(a)snoyman.com>: > > I think Aristid's aws > package[1] in particular would be good for the S3 backend. > Except currently only SimpleDB actually works. Is your XML cursor stuff ready soon? Because that's one of the reasons why I paused development. AWS involves a lot of XML and I felt that my current combination of xml + xml-monad (two packages) is not optimal or even just future-proof. > Michael > > [1] http://hackage.haskell.org/package/aws > > _______________________________________________ > web-devel mailing list > web-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/web-devel

2 3

Raw POST data
by Jeremy Hughes 31 May '11

31 May '11

Hi again, I can't find a means to access raw POST data. Both Network.Wai.Request and Yesod.Request.Request appear to only contain pre-parsed values. What am I missing? J

2 2

yesod in five minutes
by George Colpitts 30 May '11

30 May '11

Hi I tried yesod in five minutes <http://www.yesodweb.com/five-minutes> and I'm having a problem trying to add a date and time string that would update on refresh. I just want to add it to the simple page you get with yesod in 5 minutes. I can embed a date and time string that is the value of a Haskell variable but that won't refresh on update to the current date and time. My simplistic approach was to put a line in Handler/root.hs: currTimeAndDate = getClockTime but that won't compile: Handler/Root.hs:22:21: No instance for (blaze-html-0.4.1.1:Text.Blaze.ToHtml (IO ClockTime)) arising from a use of `toHtml' Possible fix: add an instance declaration for (blaze-html-0.4.1.1:Text.Blaze.ToHtml (IO ClockTime)) In the second argument of `(.)', namely `toHtml' In the expression: hamlet-0.8.2:Text.Hamlet.Quasi.htmlToHamletMonad . toHtml In a stmt of a 'do' expression: (hamlet-0.8.2:Text.Hamlet.Quasi.htmlToHamletMonad . toHtml) currTimeAndDate I'm sure it would compile if I wrapped getClockTime with unsafePerformIO to get a String but then refresh of the page wouldn't give me the current time. In addition it doesn't seem like the right way to do this. I'm sure my problem is due to my lack of knowledge of Haskell IO and monads which I do plan to learn thoroughly but right now I'd just like to get this to work. It seems like I could do it with a form in Yesod but that seems like overkill and wouldn't have the look I want. I'm very impressed with the software, the book and the source code for the www.haskellers.com. It is a testimony to the quality of all three that I have got this far, particularly considering how little I know. Any help would be greatly appreciated. Sincerely George

2 1