June 2011 - web-devel

problem with radioField from yesod.Forms
by Michael Litchard 06 Jun '11

06 Jun '11

I am working from the widget example from the Yesod web site. I was able to display a column of check boxes, and am able to generate a [Bool], which is enough for now, as far as the check boxes go. Now, I would like a column of radioFields. I will worry about the CSS and Ajax stuff later. The problem is that radioField uses a slightly different type. I admit I don't understand some of these types, but I can exploit my pattern recognition skills well enough. Below is my last attempt. The type for radioField is radioField :: (Eq x, IsForm f, FormType f ~ x) => [(x, Text)] -> FormFieldSettings -> Maybe x -> f The type for boolField is boolField :: (IsForm f, FormType f ~ Bool) => FormFieldSettings -> Maybe Bool -> f It's the [(x,Text)] that is tricking me. I suspect the problem may be me not understanding the Applicative style well enough. Could someone offer some feedback to send me on the right track? > handleFormR = do > (res, form, enctype, nonce) <- runFormPost $ fieldsToTable $ (,,,,,,,,) > <$> boolField "Server One" Nothing > <*> boolField "Server Two" Nothing > <*> boolField "Server Three" Nothing > <*> boolField "Server Four" Nothing > <*> boolField "Server Five" Nothing > <*> boolField "Server Six" Nothing > <*> boolField "Server Seven" Nothing > <*> boolField "Server Eight" Nothing > <*> radioField [(1, "Test 1"), (2, "Test 2")] "Pick a Test" Nothing mlitchard@apotheosis:~/playground/yesod-examples-0.8.0.1/src$ runhaskell nwidgets.lhs nwidgets.lhs:46:7: The last statement in a 'do' construct must be an expression: (res, form, enctype, nonce) <- runFormPost $ fieldsToTable $ (,,,,,,,,) <$> boolField "Server One" Nothing <*> boolField "Server Two" Nothing <*> boolField "Server Three" Nothing <*> boolField "Server Four" Nothing <*> boolField "Server Five" Nothing <*> boolField "Server Six" Nothing <*> boolField "Server Seven" Nothing <*> boolField "Server Eight" Nothing <*> radioField [(1, "Test 1"), (2, "Test 2")] "Test 1" Nothing

1 1

Fwd: Sending SMTP email
by Dmitry Olshansky 06 Jun '11

06 Jun '11

Hi, On Windows I use HaskellNet. Dmitry 2011/6/2 Aur Saraf <sonoflilit(a)gmail.com> > Hi, > > Michael wrote the mime-mail package that works with an external sendmail > binary. > > http://hackage.haskell.org/package/mime-mail-0.3.0 > > I'm using it and it's doing fine. > > > Cheers, > Aur > > On Thu, Jun 2, 2011 at 4:46 PM, Neil Mitchell <ndmitchell(a)gmail.com> > wrote: > > Hi > > > > I want to send an email with SMTP. I previously used hsmtpclient with > > the NoSMTPAuth option, but that library is no longer maintained by the > > original author and doesn't work with GHC 7. What do people recommend > > for sending SMTP mail? I'm not looking for anything fancy, and could > > probably fix up hsmtpclient if I needed to, but I'd rather stick to > > something some else supports. > > > > Thanks, Neil > > > > _______________________________________________ > > 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 >

2 2

Fwd: [hamlet] Clearer error for mixed spaces / tabs nesting in cassius (#2)
by Michael Snoyman 03 Jun '11

03 Jun '11

I don't have a strong opinion on tabs/spaces for Hamlet and Cassius (the discussion isn't relevant for Julius or Lucius). So I thought I'd just throw this to the web-devel list: what do you guys think? Currently, 1 tab = 4 spaces for indentation purposes. I personally never use hard tabs for Haskell, so the question doesn't affect me. Michael ---------- Forwarded message ---------- From: Shimuuar <reply+i-326148-baa0eff244395e870f290821538bf79d83ec1190(a)reply.github.com> Date: Wed, Jun 1, 2011 at 7:33 PM Subject: Re: [hamlet] Clearer error for mixed spaces / tabs nesting in cassius (#2) To: michael(a)snoyman.com I'd vote to ban tabs. They may change meaning of program silently. If your editor and hamlet/cassius have different tab width it may lead either to error or it could be parsed not as you expected. Second case is real. I encountered it. IMHO mixing tabs and significant indentation is generally bad idea™ -- Reply to this email directly or view it on GitHub: https://github.com/snoyberg/hamlet/issues/2#comment_1275487

3 3

[Yesod] Error occured in dist/devel.hs
by Katsutoshi Itoh 02 Jun '11

02 Jun '11

Hi. I converted my yesod app 0.7 to 0.8, and success to compile and run the program. but, could not run by yesod devel. ----------------------------------------- $ yesod devel (snip) Configuring kestrel-0.1... Testing files... Rebuilding app yesod: bind: resource busy (Address already in use) Preprocessing executables for kestrel-0.1... Building kestrel-0.1... Installing executable(s) in /home/cutsea110/.cabal/bin No package to register Calling runghc... dist/devel.hs:2:0: Failed to load interface for `Controller': it is not a module in the current program, or in any known package. Testing files... Testing files... Testing files... ----------------------------------------- This means what? Incidentally, ghc 6.12.3, cabal 0.8.2, haskell-platform-2010.2.0.0, yesod-0.8.1. thanks.

2 1

Sending SMTP email
by Neil Mitchell 02 Jun '11

02 Jun '11

Hi I want to send an email with SMTP. I previously used hsmtpclient with the NoSMTPAuth option, but that library is no longer maintained by the original author and doesn't work with GHC 7. What do people recommend for sending SMTP mail? I'm not looking for anything fancy, and could probably fix up hsmtpclient if I needed to, but I'd rather stick to something some else supports. Thanks, Neil

2 1

[Yesod] What is ContentFile's second argument?
by Katsutoshi Itoh 02 Jun '11

02 Jun '11

Hi Now, I'm converting my yesod app 0.7 to 0.8 I'm facing to the code like this. return $ RepHtml $ ContentFile path I looked up ContentFile has 2 arguments, on 0.8. the second argument of this is Maybe FilePart. If I write this Nothing, what does it mean? thanks.

2 1

Re: [web-devel] DTD types
by Yitzchak Gale 02 Jun '11

02 Jun '11

I wrote: >> "Note that DTD-based validation is not namespace-aware in the >> following sense: a DTD constrains the elements and attributes >> that may appear in a document by their uninterpreted names, >> not by (namespace name, local name) pairs." >> >> So in the DTD, the prefix *is* semantically significant. >> And Clark notation is irrelevant, because there is no use >> for the URI in the DTD. John Millikin wrote: > If I'm reading that paragraph correctly, the prefix is not > significant, or even present, in a DTD. You only use the local name. No, the spec is quite clear about that. Element names and attribute names are "qualified names", but their namespaces are not "interpreted"; those terms are defined precisely earlier in the spec. In order for that to produce XML documents that make sense, the spec recommends that you use #FIXED for the xmlns:foo attribute in the appropriate places in the DTD. Thanks, Yitz

1 0

Fwd: DTD types
by Yitzchak Gale 02 Jun '11

02 Jun '11

Sorry, forgot to include the list as a recipient. ---------- Forwarded message ---------- From: Yitzchak Gale Date: Wed, Jun 1, 2011 at 10:50 AM Subject: Re: DTD types To: John Millikin I 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." John Millikin wrote: >>> 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. > 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. Hmm. Then I was right in the first place. I can't use the xml-types Name type for DTDs. The XML Namespaces spec states: "Note that DTD-based validation is not namespace-aware in the following sense: a DTD constrains the elements and attributes that may appear in a document by their uninterpreted names, not by (namespace name, local name) pairs." So in the DTD, the prefix *is* semantically significant. And Clark notation is irrelevant, because there is no use for the URI in the DTD. I already uploaded a new version of dtd-types, 0.1.0.0, to Hackage, with a number of fixes, including using Name in a few places. Before I announce, I'm going to have to remove Name and uploaded another version. Thanks, Yitz

1 0

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