- web-devel - Haskell.org

Re: [web-devel] [Haskell-beginners] Options for creating a multiple select form via Yesod
by Michael Litchard 15 Jun '11

15 Jun '11

I took a look at hello-forms.hs and this was my clue myForm = fixType $ runFormGet $ renderDivs $ pure (,,,,,,) <*> areq boolField "Bool field" Nothing <*> aopt boolField "Opt bool field" Nothing <*> areq textField "Text field" Nothing <*> areq (selectField fruits) "Select field" Nothing <*> aopt (selectField fruits) "Opt select field" Nothing <*> aopt intField "Opt int field" Nothing <*> aopt (radioField fruits) "Opt radio" Nothing The aopt and areq look new. As far as I can tell, this looks like it should do what I needed. I'm eager to try it out. On Wed, Jun 15, 2011 at 3:59 PM, David McBride <dmcbride(a)neondsl.com> wrote: > I haven't finished. I was making the changes he suggested, but found > a problem. I sent him a question but he's probably a busy guy. > > I don't see the changes in his github page, where are you getting this > from? If you have found them, it is just a matter of taking the > package, cabal configure, cabal install and then it should be > available for all your coding needs. > > On Wed, Jun 15, 2011 at 6:40 PM, Michael Litchard <michael(a)schmong.org> wrote: >> David, >> I checked-out yesod-forms from the repository and see that >> you've made the changes. Thank you once again. My follow-up question >> is for anyone who cares to answer. How do I swap the new yesod-forms >> and the old one from 0.2.0? I don't want to hose >> my system. This is new ground for me. >> >> On Tue, Jun 14, 2011 at 10:56 AM, Michael Litchard <michael(a)schmong.org> wrote: >>> Oh sweet! Thanks! >>> >>> On Tue, Jun 14, 2011 at 9:43 AM, David McBride <dmcbride(a)neondsl.com> wrote: >>>> I think I'll give it a shot. Fun problem and something I'll >>>> definitely need eventually. I'll try and get you a pull request >>>> tonight if all goes well. >>>> >>>> On Tue, Jun 14, 2011 at 11:40 AM, Michael Snoyman <michael(a)snoyman.com> wrote: >>>>> Hi David, >>>>> >>>>> Thank you for the analysis, you're absolutely correct that this is a >>>>> shortcoming in the API of yesod-form as it stands. I had an idea for a >>>>> possibly simple modification to fix the situation: change fieldParse >>>>> to >>>>> >>>>> [Text] -> Either msg (Maybe a) >>>>> >>>>> We don't really want to support returning singles or doubles from the >>>>> same Field; a multiSelectField will automatically make the "a" >>>>> variable a list. Said another way, the types should be: >>>>> >>>>> selectField :: [(Text, a)] -> Field xml msg a >>>>> multiSelectField :: [(Text, a)] -> Field xml msg [a] >>>>> >>>>> Another related change: we don't really need to separate out >>>>> fieldRender from fieldView I believe. Instead, we can have fieldView >>>>> be: >>>>> >>>>> fieldView :: Text -- ^ ID >>>>> -> Text -- ^ name >>>>> -> a -- currently, this is another Text >>>>> -> Bool -- ^ required? >>>>> -> xml >>>>> >>>>> I'm willing to test out these changes myself, but wanted to (1) get >>>>> input from you and (2) see if you or anyone else wanted to take a >>>>> crack at it. >>>>> >>>>> Michael >>>>> >>>>> On Tue, Jun 14, 2011 at 4:25 PM, David McBride <dmcbride(a)neondsl.com> wrote: >>>>>> I gave a shot at this last night,and didn't quite pull it off. But I >>>>>> got pretty far and I'd rather you have my work than try it from >>>>>> scratch. >>>>>> >>>>>> The first method won't work because the Field type is used in >>>>>> validating the get parameters in the mhelper function in >>>>>> yesod.form.functions. That means that you have to have a unified type >>>>>> for field that can do everything. Maybe there is a more succinct way >>>>>> with classes, but I just couldn't think of an elegant way to do it >>>>>> that way. >>>>>> >>>>>> So what I tried to do was make the fieldParser callback into its own type: >>>>>> >>>>>> newtype FieldParser msg a = FieldParser (Either >>>>>> (Maybe Text -> Either msg (Maybe a)) >>>>>> (Maybe [Text] -> Either msg (Maybe [a]))) >>>>>> >>>>>> That means a field parser can either take one text and return one >>>>>> item, or it takes a list and returns a list of items. >>>>>> >>>>>> Then I went through Yesod.Form.Fields and changed about 12 or 15 references of >>>>>> { fieldParse = blank $ \s -> >>>>>> to >>>>>> { fieldParse = FieldParser . Left $ blank $ \s -> >>>>>> >>>>>> Cool, now when you write your multipleSelectField, you'll set the fieldParser to >>>>>> FieldParser . Right $ etc... >>>>>> >>>>>> The very last thing you have to do to fix this is the mhelper >>>>>> function, which is where I lost steam. Right now it looks up the name >>>>>> of the field in the get/post params that were passed in, and then >>>>>> hands the value to fieldParse. What it needs to do is check to see >>>>>> whether Field Parser is left or right, and then pass in the params >>>>>> slightly differently depending on which it is. I don't know how the >>>>>> parameters will end up getting passed into askParams though. Right >>>>>> now askParams returns a list of names to value pairs, so hopefully you >>>>>> will end up with a list of multiple entries for the name of your mutli >>>>>> select and a different value for each entry, which you need to filter >>>>>> out and collect into a single list and then run the fieldParser on it. >>>>>> >>>>>> Hopefully that is not too bad. >>>>>> >>>>>> >>>>>> On Tue, Jun 14, 2011 at 4:30 AM, Michael Litchard <michael(a)schmong.org> wrote: >>>>>>> Well I will try the easier way first, and having accomplished that I >>>>>>> will look into doing it the better way. If people can call dibs, I'd >>>>>>> like to. >>>>>>> >>>>>>> On Mon, Jun 13, 2011 at 9:47 PM, David McBride <dmcbride(a)neondsl.com> wrote: >>>>>>>> After looking at the source, you should be aware that >>>>>>>> >>>>>>>> 1) yesod-form has been updated to 2.0, >>>>>>>> 2) it is a lot easier to understand than 1.x was. >>>>>>>> >>>>>>>> The main obstacle I see is that the library uses the Field datatype, >>>>>>>> that has a fieldParse method of Maybe Text -> Either msg (Maybe a). >>>>>>>> The problem with that is that a multiple select box should require >>>>>>>> [Text] or perhaps Maybe [Text] rather than Maybe Text. It is making >>>>>>>> the assumption that there can only be one piece of data per field, >>>>>>>> which holds for everything except multiple selects and multiple radio >>>>>>>> buttons. >>>>>>>> >>>>>>>> So looking at this, it looks like you'd have to add another field type >>>>>>>> "FieldMulti" to Yesod/Form/Types.hs, which allows for multiple values. >>>>>>>> Then add a new version of selectFieldHelper that accepts fieldMultis >>>>>>>> instead of fields, and then it is trivial to change selectField to be >>>>>>>> a multi field. >>>>>>>> >>>>>>>> Alternatively you could change Field to accept either single or >>>>>>>> multiple values and change its use everywhere else, which is probably >>>>>>>> the better answer, but more involved. >>>>>>>> >>>>>>>> I don't know if this is the best way to go about it, but it seems like >>>>>>>> it should work. >>>>>>>> >>>>>>>> On Mon, Jun 13, 2011 at 8:11 PM, Michael Litchard <michael(a)schmong.org> wrote: >>>>>>>>> Thank you David. I'm trying to figure out step-by-step, exactly how >>>>>>>>> selectFields binds field values. One thing I'm having trouble with is >>>>>>>>> visualizing return values. >>>>>>>>> Beginning with askParams. >>>>>>>>> >>>>>>>>> askParams :: Monad m => StateT Ints (ReaderT Env m) Env >>>>>>>>> askParams = lift askenv <- askParams >>>>>>>>> >>>>>>>>> >>>>>>>>> Here's the example from selectFields >>>>>>>>> env <- askParams >>>>>>>>> later on env is used in with the lookup function >>>>>>>>> >>>>>>>>> let res = case lookup name env of >>>>>>>>> seeing as lookup is checking for value of type a in a [(a,b)] >>>>>>>>> and given the type of askParams >>>>>>>>> I have no idea what is going on here. I don't see a [(a,b)] in >>>>>>>>> askParams :: Monad m => StateT Ints (ReaderT Env m) Env. >>>>>>>>> >>>>>>>>> So if someone could answer how env <- askParams yields a [(a,b)] for >>>>>>>>> lookup to use as input, I would appreciate it. >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jun 13, 2011 at 2:54 PM, David McBride <dmcbride(a)neondsl.com> wrote: >>>>>>>>>> The read function is sort of the opposite of the show function. Take >>>>>>>>>> a string, give me a value. reads is like read, however it has some >>>>>>>>>> traits that read doesn't have. >>>>>>>>>> >>>>>>>>>> The problem with read is that if you go: read "asdf" :: Int, it will >>>>>>>>>> die with an exception, and that is something you don't want in a web >>>>>>>>>> app. Also it doesn't tell you what the rest of the string is, so you >>>>>>>>>> have no real way of finding out what was left of the string after the >>>>>>>>>> part you wanted to parse. >>>>>>>>>> >>>>>>>>>> So there is the reads function that returns [(a,String)] which is a >>>>>>>>>> list of pairs of the answer a, and the rest of the string String. As >>>>>>>>>> a bonus, it returns a list so if it can't parse the string you pass >>>>>>>>>> it, then it just returns an empty list. Why didn't it use Maybe you >>>>>>>>>> ask? I bet it probably has to do with the function being one of the >>>>>>>>>> first functions ever written for haskell, long before Maybe existed. >>>>>>>>>> >>>>>>>>>> So all it is there is unpack this bytestring into a string, then parse >>>>>>>>>> it into a value, and please don't blow up if the input is invalid. >>>>>>>>>> >>>>>>>>>> On Mon, Jun 13, 2011 at 5:28 PM, Michael Litchard <michael(a)schmong.org> wrote: >>>>>>>>>>> I was a bit hasty. I can render a multi-select field easily enough. >>>>>>>>>>> However, I'm having difficulty following how selectField makes a value >>>>>>>>>>> from the select field accessible from the handler code calling >>>>>>>>>>> selectField. Once I figure that out, I can modify multiSelectField >>>>>>>>>>> accordingly. >>>>>>>>>>> >>>>>>>>>>> The goal here being to modify selectField so that a list of field >>>>>>>>>>> values can be bound . >>>>>>>>>>> >>>>>>>>>>> Here's what I have so far: >>>>>>>>>>> multiSelectField is thus far identical in every way to selectField >>>>>>>>>>> save for the following change in the Hamlet part. >>>>>>>>>>> >>>>>>>>>>> <select multiple="#{theId}" id="#{theId}" name="#{name}"> >>>>>>>>>>> >>>>>>>>>>> My thinking was that the value bound to multiple was arbitary, and I'd >>>>>>>>>>> use theId until I figured out something that made more sense. >>>>>>>>>>> >>>>>>>>>>> Here's where I am focusing my efforts next >>>>>>>>>>> >>>>>>>>>>> http://hpaste.org/47774 >>>>>>>>>>> >>>>>>>>>>> Specifically >>>>>>>>>>> (x', _):_ -> >>>>>>>>>>> case lookup x' pairs' of >>>>>>>>>>> Nothing -> FormFailure ["Invalid entry"] >>>>>>>>>>> Just (y, _) -> FormSuccess y >>>>>>>>>>> I'm thinking this is where selectField binds a value from the select >>>>>>>>>>> field form. I'm confused by the (x',_):_. At first I thought it meant >>>>>>>>>>> that just the first pair in a list of pairs is pattern matched >>>>>>>>>>> against, and the rest discarded. But then I ask myself where the list >>>>>>>>>>> is coming from. In a select field there would only be one pair, not a >>>>>>>>>>> list of them. Here's where I get confused. Because if this is not >>>>>>>>>>> where the values of the select field get bound, I don't know where >>>>>>>>>>> it's happening. >>>>>>>>>>> >>>>>>>>>>> Is my confusion clear enough such that I could get some clarifying >>>>>>>>>>> feedback? If not, what is unclear? >>>>>>>>>>> >>>>>>>>>>> On Sat, Jun 11, 2011 at 11:03 AM, Michael Snoyman <michael(a)snoyman.com> wrote: >>>>>>>>>>>> The best way for code contributions in general is to submit a pull >>>>>>>>>>>> request on Github. If that's a problem, sending a patch via email >>>>>>>>>>>> works as well (either directly to me or to web-devel). >>>>>>>>>>>> >>>>>>>>>>>> Michael >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jun 11, 2011 at 1:14 AM, Michael Litchard <michael(a)schmong.org> wrote: >>>>>>>>>>>>> Hey! I just added multiSelectField to the Forms library. I'm only >>>>>>>>>>>>> getting the first value selected, but I think that's because of how >>>>>>>>>>>>> I'm using multiSelecrField. I'm going to try to change the client code >>>>>>>>>>>>> to fix this. I'll let you know how it goes. when I get a >>>>>>>>>>>>> maybeMultiSelectField added I'll show you what I have. What would be >>>>>>>>>>>>> the best way to submit this? >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Jun 9, 2011 at 10:05 PM, Michael Snoyman <michael(a)snoyman.com> wrote: >>>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>>> >>>>>>>>>>>>>> There's nothing jQuery or Javascript specific about a multi-select >>>>>>>>>>>>>> field: it's just a normal select field with a "multiple" attribute. I >>>>>>>>>>>>>> would recommend taking the selectField code from yesod-form and >>>>>>>>>>>>>> modifying it to be multi-select. I'll likely do this myself >>>>>>>>>>>>>> eventually, but it could be a good learning experience in Yesod (and a >>>>>>>>>>>>>> great introduction to contributing to the framework if you're so >>>>>>>>>>>>>> inclined). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Michael >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Jun 9, 2011 at 8:29 PM, Michael Litchard <michael(a)schmong.org> wrote: >>>>>>>>>>>>>>> I'm trying to create a multiple select form, as illustrated on the following: >>>>>>>>>>>>>>> http://api.jquery.com/selected-selector/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here's the options I see possible: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (1) Write a jQuery widget. >>>>>>>>>>>>>>> (2) Use plain javascript via Julius >>>>>>>>>>>>>>> (3) Use the low-level functions in Yesod.Form to write a widget >>>>>>>>>>>>>>> (4) Use a pre-existing function that does what I need, but am not >>>>>>>>>>>>>>> aware of this functionality >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (1) has appeal as it looks like something small I can contribute to >>>>>>>>>>>>>>> the project. It will take me some extra time to figure out the >>>>>>>>>>>>>>> details. But, I had a look at the other jQuery widgets and they seem >>>>>>>>>>>>>>> to provide an approachable model to follow. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (2) This looks like the most straight-forward approach. I'm just >>>>>>>>>>>>>>> learning javascript so would have to figure out how to capture values >>>>>>>>>>>>>>> in Haskell from the form. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (3) This looks like the most difficult way. I don't think I know >>>>>>>>>>>>>>> enough about the low-level functions in Yesod.Form to be able to >>>>>>>>>>>>>>> accomplish this in a timely manner. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (4) This is the best scenario. There's already a way to do this right >>>>>>>>>>>>>>> now, and I just haven't identified it. If this is the case, I would >>>>>>>>>>>>>>> appreciate being pointed in the right direction. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Until informed otherwise, I'm evaluating options 1 and 2. All feedback >>>>>>>>>>>>>>> welcomed. Thanks to all who made Yesod possible. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Beginners mailing list >>>>>>>>>>>>>>> Beginners(a)haskell.org >>>>>>>>>>>>>>> http://www.haskell.org/mailman/listinfo/beginners >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Beginners mailing list >>>>>>>>>>> Beginners(a)haskell.org >>>>>>>>>>> http://www.haskell.org/mailman/listinfo/beginners >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Beginners mailing list >>>>>>>>>> Beginners(a)haskell.org >>>>>>>>>> http://www.haskell.org/mailman/listinfo/beginners >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Beginners mailing list >>>>>>>> Beginners(a)haskell.org >>>>>>>> http://www.haskell.org/mailman/listinfo/beginners >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Beginners mailing list >>>>>> Beginners(a)haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/beginners >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Beginners mailing list >>>> Beginners(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/beginners >>>> >>> >> >

1 1

unicode domain and path
by Jeremy Hughes 14 Jun '11

14 Jun '11

Hi, The type of both host and path fields of http-enumerator's Request type is ByteString/Ascii. Does this mean using unicode URLs vai encodeUtf8 is a no go? J

3 5

[Yesod] i18n for julius
by Katsutoshi Itoh 14 Jun '11

14 Jun '11

Hi we can't use _{MsgFoo} in julius file, can we? Could u support this facility? (of course, syntax is up to u) thanks.

2 2

Re: [web-devel] [Haskell-beginners] Options for creating a multiple select form via Yesod
by Michael Snoyman 14 Jun '11

14 Jun '11

Hi David, Thank you for the analysis, you're absolutely correct that this is a shortcoming in the API of yesod-form as it stands. I had an idea for a possibly simple modification to fix the situation: change fieldParse to [Text] -> Either msg (Maybe a) We don't really want to support returning singles or doubles from the same Field; a multiSelectField will automatically make the "a" variable a list. Said another way, the types should be: selectField :: [(Text, a)] -> Field xml msg a multiSelectField :: [(Text, a)] -> Field xml msg [a] Another related change: we don't really need to separate out fieldRender from fieldView I believe. Instead, we can have fieldView be: fieldView :: Text -- ^ ID -> Text -- ^ name -> a -- currently, this is another Text -> Bool -- ^ required? -> xml I'm willing to test out these changes myself, but wanted to (1) get input from you and (2) see if you or anyone else wanted to take a crack at it. Michael On Tue, Jun 14, 2011 at 4:25 PM, David McBride <dmcbride(a)neondsl.com> wrote: > I gave a shot at this last night,and didn't quite pull it off. But I > got pretty far and I'd rather you have my work than try it from > scratch. > > The first method won't work because the Field type is used in > validating the get parameters in the mhelper function in > yesod.form.functions. That means that you have to have a unified type > for field that can do everything. Maybe there is a more succinct way > with classes, but I just couldn't think of an elegant way to do it > that way. > > So what I tried to do was make the fieldParser callback into its own type: > > newtype FieldParser msg a = FieldParser (Either > (Maybe Text -> Either msg (Maybe a)) > (Maybe [Text] -> Either msg (Maybe [a]))) > > That means a field parser can either take one text and return one > item, or it takes a list and returns a list of items. > > Then I went through Yesod.Form.Fields and changed about 12 or 15 references of > { fieldParse = blank $ \s -> > to > { fieldParse = FieldParser . Left $ blank $ \s -> > > Cool, now when you write your multipleSelectField, you'll set the fieldParser to > FieldParser . Right $ etc... > > The very last thing you have to do to fix this is the mhelper > function, which is where I lost steam. Right now it looks up the name > of the field in the get/post params that were passed in, and then > hands the value to fieldParse. What it needs to do is check to see > whether Field Parser is left or right, and then pass in the params > slightly differently depending on which it is. I don't know how the > parameters will end up getting passed into askParams though. Right > now askParams returns a list of names to value pairs, so hopefully you > will end up with a list of multiple entries for the name of your mutli > select and a different value for each entry, which you need to filter > out and collect into a single list and then run the fieldParser on it. > > Hopefully that is not too bad. > > > On Tue, Jun 14, 2011 at 4:30 AM, Michael Litchard <michael(a)schmong.org> wrote: >> Well I will try the easier way first, and having accomplished that I >> will look into doing it the better way. If people can call dibs, I'd >> like to. >> >> On Mon, Jun 13, 2011 at 9:47 PM, David McBride <dmcbride(a)neondsl.com> wrote: >>> After looking at the source, you should be aware that >>> >>> 1) yesod-form has been updated to 2.0, >>> 2) it is a lot easier to understand than 1.x was. >>> >>> The main obstacle I see is that the library uses the Field datatype, >>> that has a fieldParse method of Maybe Text -> Either msg (Maybe a). >>> The problem with that is that a multiple select box should require >>> [Text] or perhaps Maybe [Text] rather than Maybe Text. It is making >>> the assumption that there can only be one piece of data per field, >>> which holds for everything except multiple selects and multiple radio >>> buttons. >>> >>> So looking at this, it looks like you'd have to add another field type >>> "FieldMulti" to Yesod/Form/Types.hs, which allows for multiple values. >>> Then add a new version of selectFieldHelper that accepts fieldMultis >>> instead of fields, and then it is trivial to change selectField to be >>> a multi field. >>> >>> Alternatively you could change Field to accept either single or >>> multiple values and change its use everywhere else, which is probably >>> the better answer, but more involved. >>> >>> I don't know if this is the best way to go about it, but it seems like >>> it should work. >>> >>> On Mon, Jun 13, 2011 at 8:11 PM, Michael Litchard <michael(a)schmong.org> wrote: >>>> Thank you David. I'm trying to figure out step-by-step, exactly how >>>> selectFields binds field values. One thing I'm having trouble with is >>>> visualizing return values. >>>> Beginning with askParams. >>>> >>>> askParams :: Monad m => StateT Ints (ReaderT Env m) Env >>>> askParams = lift askenv <- askParams >>>> >>>> >>>> Here's the example from selectFields >>>> env <- askParams >>>> later on env is used in with the lookup function >>>> >>>> let res = case lookup name env of >>>> seeing as lookup is checking for value of type a in a [(a,b)] >>>> and given the type of askParams >>>> I have no idea what is going on here. I don't see a [(a,b)] in >>>> askParams :: Monad m => StateT Ints (ReaderT Env m) Env. >>>> >>>> So if someone could answer how env <- askParams yields a [(a,b)] for >>>> lookup to use as input, I would appreciate it. >>>> >>>> >>>> On Mon, Jun 13, 2011 at 2:54 PM, David McBride <dmcbride(a)neondsl.com> wrote: >>>>> The read function is sort of the opposite of the show function. Take >>>>> a string, give me a value. reads is like read, however it has some >>>>> traits that read doesn't have. >>>>> >>>>> The problem with read is that if you go: read "asdf" :: Int, it will >>>>> die with an exception, and that is something you don't want in a web >>>>> app. Also it doesn't tell you what the rest of the string is, so you >>>>> have no real way of finding out what was left of the string after the >>>>> part you wanted to parse. >>>>> >>>>> So there is the reads function that returns [(a,String)] which is a >>>>> list of pairs of the answer a, and the rest of the string String. As >>>>> a bonus, it returns a list so if it can't parse the string you pass >>>>> it, then it just returns an empty list. Why didn't it use Maybe you >>>>> ask? I bet it probably has to do with the function being one of the >>>>> first functions ever written for haskell, long before Maybe existed. >>>>> >>>>> So all it is there is unpack this bytestring into a string, then parse >>>>> it into a value, and please don't blow up if the input is invalid. >>>>> >>>>> On Mon, Jun 13, 2011 at 5:28 PM, Michael Litchard <michael(a)schmong.org> wrote: >>>>>> I was a bit hasty. I can render a multi-select field easily enough. >>>>>> However, I'm having difficulty following how selectField makes a value >>>>>> from the select field accessible from the handler code calling >>>>>> selectField. Once I figure that out, I can modify multiSelectField >>>>>> accordingly. >>>>>> >>>>>> The goal here being to modify selectField so that a list of field >>>>>> values can be bound . >>>>>> >>>>>> Here's what I have so far: >>>>>> multiSelectField is thus far identical in every way to selectField >>>>>> save for the following change in the Hamlet part. >>>>>> >>>>>> <select multiple="#{theId}" id="#{theId}" name="#{name}"> >>>>>> >>>>>> My thinking was that the value bound to multiple was arbitary, and I'd >>>>>> use theId until I figured out something that made more sense. >>>>>> >>>>>> Here's where I am focusing my efforts next >>>>>> >>>>>> http://hpaste.org/47774 >>>>>> >>>>>> Specifically >>>>>> (x', _):_ -> >>>>>> case lookup x' pairs' of >>>>>> Nothing -> FormFailure ["Invalid entry"] >>>>>> Just (y, _) -> FormSuccess y >>>>>> I'm thinking this is where selectField binds a value from the select >>>>>> field form. I'm confused by the (x',_):_. At first I thought it meant >>>>>> that just the first pair in a list of pairs is pattern matched >>>>>> against, and the rest discarded. But then I ask myself where the list >>>>>> is coming from. In a select field there would only be one pair, not a >>>>>> list of them. Here's where I get confused. Because if this is not >>>>>> where the values of the select field get bound, I don't know where >>>>>> it's happening. >>>>>> >>>>>> Is my confusion clear enough such that I could get some clarifying >>>>>> feedback? If not, what is unclear? >>>>>> >>>>>> On Sat, Jun 11, 2011 at 11:03 AM, Michael Snoyman <michael(a)snoyman.com> wrote: >>>>>>> The best way for code contributions in general is to submit a pull >>>>>>> request on Github. If that's a problem, sending a patch via email >>>>>>> works as well (either directly to me or to web-devel). >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> On Sat, Jun 11, 2011 at 1:14 AM, Michael Litchard <michael(a)schmong.org> wrote: >>>>>>>> Hey! I just added multiSelectField to the Forms library. I'm only >>>>>>>> getting the first value selected, but I think that's because of how >>>>>>>> I'm using multiSelecrField. I'm going to try to change the client code >>>>>>>> to fix this. I'll let you know how it goes. when I get a >>>>>>>> maybeMultiSelectField added I'll show you what I have. What would be >>>>>>>> the best way to submit this? >>>>>>>> >>>>>>>> On Thu, Jun 9, 2011 at 10:05 PM, Michael Snoyman <michael(a)snoyman.com> wrote: >>>>>>>>> Hi Michael, >>>>>>>>> >>>>>>>>> There's nothing jQuery or Javascript specific about a multi-select >>>>>>>>> field: it's just a normal select field with a "multiple" attribute. I >>>>>>>>> would recommend taking the selectField code from yesod-form and >>>>>>>>> modifying it to be multi-select. I'll likely do this myself >>>>>>>>> eventually, but it could be a good learning experience in Yesod (and a >>>>>>>>> great introduction to contributing to the framework if you're so >>>>>>>>> inclined). >>>>>>>>> >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> On Thu, Jun 9, 2011 at 8:29 PM, Michael Litchard <michael(a)schmong.org> wrote: >>>>>>>>>> I'm trying to create a multiple select form, as illustrated on the following: >>>>>>>>>> http://api.jquery.com/selected-selector/ >>>>>>>>>> >>>>>>>>>> Here's the options I see possible: >>>>>>>>>> >>>>>>>>>> (1) Write a jQuery widget. >>>>>>>>>> (2) Use plain javascript via Julius >>>>>>>>>> (3) Use the low-level functions in Yesod.Form to write a widget >>>>>>>>>> (4) Use a pre-existing function that does what I need, but am not >>>>>>>>>> aware of this functionality >>>>>>>>>> >>>>>>>>>> (1) has appeal as it looks like something small I can contribute to >>>>>>>>>> the project. It will take me some extra time to figure out the >>>>>>>>>> details. But, I had a look at the other jQuery widgets and they seem >>>>>>>>>> to provide an approachable model to follow. >>>>>>>>>> >>>>>>>>>> (2) This looks like the most straight-forward approach. I'm just >>>>>>>>>> learning javascript so would have to figure out how to capture values >>>>>>>>>> in Haskell from the form. >>>>>>>>>> >>>>>>>>>> (3) This looks like the most difficult way. I don't think I know >>>>>>>>>> enough about the low-level functions in Yesod.Form to be able to >>>>>>>>>> accomplish this in a timely manner. >>>>>>>>>> >>>>>>>>>> (4) This is the best scenario. There's already a way to do this right >>>>>>>>>> now, and I just haven't identified it. If this is the case, I would >>>>>>>>>> appreciate being pointed in the right direction. >>>>>>>>>> >>>>>>>>>> Until informed otherwise, I'm evaluating options 1 and 2. All feedback >>>>>>>>>> welcomed. Thanks to all who made Yesod possible. >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Beginners mailing list >>>>>>>>>> Beginners(a)haskell.org >>>>>>>>>> http://www.haskell.org/mailman/listinfo/beginners >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Beginners mailing list >>>>>> Beginners(a)haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/beginners >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Beginners mailing list >>>>> Beginners(a)haskell.org >>>>> http://www.haskell.org/mailman/listinfo/beginners >>>>> >>>> >>> >>> _______________________________________________ >>> Beginners mailing list >>> Beginners(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/beginners >>> >> > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners >

1 0

mkToForm
by Alexander Dunlap 13 Jun '11

13 Jun '11

Hi, Is mkToForm still supported in the current Yesod? It seems like things are breaking with the conversion of everything to Text. If you don't have OverloadedStrings enabled, the compiler complains that the string literals generated by mkToForm are not Text-compatible, but if you do have OverloadedSrings enabled, the compiler complains about toHtml "" being ambiguous. Is there a good solution to this or is it recommended to no longer use mkToForm - in that case, what is the easiest way to replace it? Thanks, Alex

2 1

"yesod devel" and sandbox'ed environment
by "Timo B. Hübel" 13 Jun '11

13 Jun '11

Hi, is it possible to have a sandbox'ed environment like cabal-dev together with this new "yesod devel"-environment? I've just thrown together a quick test with cabal-dev and a scaffolded yesod site, but calling "yesod devel" just gives me a bunch of missing dependencies. Any hints are highly appreciated. Thank you, Timo

3 4

built with yesod badges anyone?
by Max Cantor 13 Jun '11

13 Jun '11

http://hachicode.com is alive and IMHO is desperately in need of a "built with yesod" badge on the bottom. Michael, do you have any graphics? Anyone? Max

3 2

Re: [web-devel] xml-types IsString instance for Name causes crashes
by Yitzchak Gale 13 Jun '11

13 Jun '11

I wrote: >> 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. Or accidentally omits the '}' in Clark notation. The way xml-types is now, it cannot be used in an environment where code is not allowed to introduce any additional risk of crashes. That is quite common in commercial development. John Millikin wrote: > If you are concerned that a developer may cause exceptions > by writing incorrect code, it would be better to use the Name > constructor directly. The only way to ensure that the IsString will not be used would be to remove the instance entirely from xml-types. In GHC there is no way to prevent an instance from being imported when you import any part of a module. But that would be a shame - I have been using xml-types extensively, and I don't think I have used the Name constructor directly even once. It's just so much neater to use the IsString instance. If you don't like my suggestion of what fromString should do when Clark notation fails to parse, that's OK, do something else. As long as it doesn't crash. Let me put it another way. The IsString class was introduced mainly for ByteString and Text; it's a way for other string implementations to hook into Haskell's built-in special syntax for string literals. I think your Name type does qualify though - it really is just a kind of string, with special support for XML namespaces. But people would be really, really surprised if their program crashed at runtime (possibly for a customer) just because of certain characters they included in a string literal. It is very important for any implementation of the fromString method to be total. Thanks, Yitz

6 14

Yesod: Issue with getAuthId never getting executed
by Mathew de Detrich 10 Jun '11

10 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)

2 1

Yesod: unifying breadcrumbs and routes
by Eric Schug 10 Jun '11

10 Jun '11

There seems to be much redundant information created within the Yesod structure. One place to define the routes Another place defines the route hierarchy for breadcrumbs with titles. A third place defines, but not integrated into Yesod, defines use menus (usually similar hierarchy and titles). Would it be possible to have all of this defined into one place, by extending the routes definition using white space hierarchy similar to hamlet definition. and optionally include Title name. -- Example config/routes /static StaticR Static getStatic /favicon.ico FaviconR GET /robots.txt RobotsR GET / RootR GET "Home" /contact ContactR GET "Contact Us" /services ServicesR GET "Our Services" /services/stuffwedo StuffWeDoR GET "Stuff We Do" The resource list would be expanded to include this hierarchy. Something like Resource String <http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/Data-Char…> [Piece <http://hackage.haskell.org/packages/archive/web-routes-quasi/0.6.3/doc/html…>] [String <http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/Data-Char…>] String Maybe String From this a breadcrumb could be build from a maker (if desired). mkYesodData "Example" $(parseRoutesFile "config/routes") mkYesodBreadcrumbs "Example" resourcesExample -- creates breadcrumbsExample and a hierarchy useful for building Menus mkYesodHierarchy "Example" resourcesExample -- creates a nested table of (Route, Html) pairs The menu list could also be pulled from the data, with possible few options.

3 2