Hi again,

I just realized that I never figured out how to get radio-groups not to
raise an error when no option is selected. I manage to put defaults for
input-string and so on, by doing what Jay suggested and redefining my own
through the use of 'default and 'input.

In the case of radio-group, what I want is to have a default (or #f) value
when no value has been picked and resend the form for the user to complete
it. Since there is some magic going on with formlet-process of radio-group
that I do not understand, I couldn't figure out where to hack it to make it
accept no values (it blows up trying to call 'first on a list that contains
no values).

As I mentioned earlier, I can hack this by adding a hidden radio button
which I check by default, but that is a suboptimal solution.

I'm happy to try and implement something reuseable for other people, if I
can be pointed at the right part of the code. I followed the code from
formlet-process to request-bindings/raw to request-bindings/raw promise,
which apparently is defined (somehow) via

(define-serializable-struct
  request
  (method uri headers/raw bindings/raw-promise post-data/raw
          host-ip host-port client-ip)
  #:transparent)

I looked at the defining file of define-serializable-struct and gave up.

Thanks,
Marc

On Mon, Jan 25, 2016 at 2:54 PM, Marc Kaufmann <marc.kaufman...@gmail.com>
wrote:

> Done, although since it is my first pull request, let me know if I did it
> wrong (tried first without forking, which of course was nonsense).
>
> I tried to find a way to have the 'id' on radio the same as the 'for' on
> label, but I couldn't figure out well enough what is going on.
>
> Cheers,
> Marc
>
> On Mon, Jan 18, 2016 at 10:50 AM, Jay McCarthy <jay.mccar...@gmail.com>
> wrote:
>
>> 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