Great Marc.

If you want, you could submit a pull-request and we could add the wrap
thing to the main library.

Jay

On Wed, Jan 13, 2016 at 5:00 PM, Marc Kaufmann
<marc.kaufman...@gmail.com> wrote:
> So, turns out I can answer my own question, if ugly hacks count.
>
> I copy-pasted (yep, DRY is my guiding principle: Do Repeat Yourself) the
> code for radio-group and the functions it depends on and changed the part of
> the code that creates the HTML in 'input-group' from
>
>              (for/list ([vn (in-range i)])
>                        (define e (hash-ref value->element vn))
>                        (define v (number->string vn))
>                        (list
>                         `(input ([name ,name]
>                                  [type ,kind]
>                                  [value ,v]
>                                  ,@(if (checked? e)
>                                        '([checked "true"])
>                                        empty)
>                                  ,@(attrs e)))
>                         (display e))))))))
>
> to
>
>              (for/list ([vn (in-range i)])
>                        (define e (hash-ref value->element vn))
>                        (define v (number->string vn))
>                        (wrap e (string-append name "-" v)
>                         `(input ([name ,name]
>                                  [type ,kind]
>                                  [value ,v]
>                                  ,@(if (checked? e)
>                                        '([checked "true"])
>                                        empty)
>                                  ,@(attrs e))))))))))
>
>
> The string-append is hard-coding for the id I want to put on the label and
> input (which I am failing to get done right now). It now works when I use
> the following definition of radio-group/bootstrap:
>
> (define (wrap/bootstrap e id input)
>   (list
>     `(div ((class "form-group"))
>         (label ((for ,id))
>                ,input
>                ,e))))
>
> (define (radio-group/bootstrap l
>                      #:attributes [attrs (λ (x) empty)]
>                      #:checked? [checked? (λ (x) #f)])
>   (input-group/wrap l
>                #:kind "radio"
>                #:attributes attrs
>                #:checked? checked?
>                #:wrap wrap/bootstrap))
>
>
> It is not particularly pretty, I do not understand the code in input-group,
> and I seem to be incapable of figuring out whether to return (list 'div ...)
> or (list '(div ...))  (or whether to include it via ,(function-call ...) or
> ,@(function-call ...)), but it works for me now (modulo a missing 'id'
> attribute on <input>, but I will hack that on the client side via jQuery).
>
> Anyway, while any improvements to my (already aesthetic) solution are
> appreciated, I am good for what I need right now.
>
> Cheers,
> Marc
>
> On Wed, Jan 13, 2016 at 12:26 PM, Marc Kaufmann <marc.kaufman...@gmail.com>
> wrote:
>>
>> Thanks Jay.
>>
>> On Mon, Jan 11, 2016 at 11:15 AM, Jay McCarthy <jay.mccar...@gmail.com>
>> wrote:
>>>
>>> Hi Marc,
>>>
>>> Most formlets are typed as `(formlet/c (or/c false/c binding?))` where
>>> the `binding?` is returned when the thing is there and the `#f` is
>>> returned when it isn't. However, if you use `required`, then an
>>> exception is thrown on the `#f` because the form element must be
>>> present. Formlets like `input-string` include a call to `required`. I
>>> think that you either want to handle the `#f` or use `default` to have
>>> a default value present. Similarly most formlets like `text-input`
>>> have an optional `#:value` keyword for starting them off with a value.
>>>
>>
>> Since I use radio-group, is there a way to make it not blow up if it
>> doesn't get a value on any button, it seems that it works differently from
>> the text inputs. Of course, I could hack this by adding a hidden button and
>> marking it as checked, but that's a bit of a hack (not that I am opposed to
>> hacks).
>>
>>>
>>> I think a better form DSL could be built out of formlets that
>>> automatically did client & server-side checking with looping
>>> re-submission until correct, etc. But that's not what formlets are yet
>>> and you have to roll it yourself.
>>>
>>> Jay
>>>
>>
>> I thought so.
>>
>> A related question on radio-groups though: #:display allows me to add some
>> custom HTML per radio input, but only after the radio input tag. Is there a
>> way to wrap each radio input in a div? I ask because I am using Bootstrap
>> for styling, which requires the following HTML:
>>
>> <div class="radio">
>>   <label>
>>     <input type="radio" name="optionsRadios" id="optionsRadios1"
>> value="option1">
>>     Option one is this.
>>   </label>
>> </div>
>>
>> Is this something that would be easy to add to (some version of)
>> radio-group? I am using this in several places (different radio groups), so
>> I would really like to leverage the formlet-process and formlets-display
>> abstraction, but I don't see how I would build a custom radio-group/wrap
>> that takes advantage of formlets by picking only the checked radio, gives
>> them all the same name, yet allows me to wrap it all.
>>
>> Thanks for all the replies, hopefully at some point I actually understand
>> what I am doing and can answer questions.
>>
>> Marc
>>
>>>
>>>
>>> On Sun, Jan 10, 2016 at 9:05 PM, Marc Kaufmann
>>> <marc.kaufman...@gmail.com> wrote:
>>> > Thanks.
>>> >
>>> > Another question about formlets: when I use (formlet-process
>>> > formlet-name)
>>> > it will often raise errors when a field doesn't have a value. Is there
>>> > an
>>> > easy way of capturing errors, in particular to show the form as it was
>>> > entered by the user, but with an error message at the top, rather than
>>> > blowing up?
>>> >
>>> > One way I can imagine doing this is to catch the errors via
>>> > (with-handlers
>>> > ... ), and then resend the form with previous answers pre-populated.
>>> > So, I
>>> > would do the following, where 'answer' is the string ("Yes" or "No")
>>> > that
>>> > was associated with the checked answer previously.
>>> >
>>> > (define (rg-formlet answer)
>>> >   (define (was-answer? a)
>>> >     (equal? a answer))
>>> >   (formlet
>>> >     (label
>>> >       ,{(radio-group '("Yes" "No") #:checked was-answer?) . => .
>>> > answer})
>>> >     answer))
>>> >
>>> > Is this the way to do it, or is there an easier way (since forms with
>>> > missing elements can't be such a rarity - and yes, I'll do checking on
>>> > the
>>> > client-side as well).
>>> >
>>> > Thanks,
>>> > Marc
>>> >
>>> > On Sun, Jan 10, 2016 at 5:08 PM, Jay McCarthy <jay.mccar...@gmail.com>
>>> > wrote:
>>> >>
>>> >> On Sun, Jan 10, 2016 at 3:50 PM, Marc Kaufmann
>>> >> <marc.kaufman...@gmail.com> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > I manage to get the basic formlets to work, and tried the
>>> >> > radiogroup,
>>> >> > but it
>>> >> > fails with the following error: "input-group: invalid selection #f",
>>> >> > even
>>> >> > though I had it selected. After some playing around, I saw that
>>> >> > there
>>> >> > are
>>> >> > two input_0 fields being sent on submit, since I have another
>>> >> > formlet on
>>> >> > the
>>> >> > same page (with a separate formlet-display and formlet-process).
>>> >> >
>>> >> > My question is: If I use formlets, do I have to put all the formlets
>>> >> > into
>>> >> > one big formlet on every page, as otherwise fields will have the
>>> >> > same
>>> >> > name
>>> >> > attribute, and there will be clashes?
>>> >>
>>> >> Each form can have only one formlet. There can be different forms on a
>>> >> page, I believe.
>>> >>
>>> >> Jay
>>> >>
>>> >> > Thanks,
>>> >> > Marc
>>> >> >
>>> >> >
>>> >> > --
>>> >> > You received this message because you are subscribed to the Google
>>> >> > Groups
>>> >> > "Racket Users" group.
>>> >> > To unsubscribe from this group and stop receiving emails from it,
>>> >> > send
>>> >> > an
>>> >> > email to racket-users+unsubscr...@googlegroups.com.
>>> >> > For more options, visit https://groups.google.com/d/optout.
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Jay McCarthy
>>> >> Associate Professor
>>> >> PLT @ CS @ UMass Lowell
>>> >> http://jeapostrophe.github.io
>>> >>
>>> >>            "Wherefore, be not weary in well-doing,
>>> >>       for ye are laying the foundation of a great work.
>>> >> And out of small things proceedeth that which is great."
>>> >>                           - D&C 64:33
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Jay McCarthy
>>> Associate Professor
>>> PLT @ CS @ UMass Lowell
>>> http://jeapostrophe.github.io
>>>
>>>            "Wherefore, be not weary in well-doing,
>>>       for ye are laying the foundation of a great work.
>>> And out of small things proceedeth that which is great."
>>>                           - D&C 64:33
>>
>>
>



-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to