Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Case for handling implicit/explicit forms with <|> #52

Closed
wants to merge 1 commit into from

Conversation

BartAdv
Copy link
Contributor

@BartAdv BartAdv commented Aug 5, 2014

test = step $ do
  i <- page $
         (wform $ getInt (Just 1)) <! [("class", "foo")]
       <|> do
             submitButton "ok"
             --noWidget -- works if there is widget that does not produce HasElems
             return 0

  page $ p "hola" ++> noWidget

In above case, my explicit form laters gets removed and replaced by implicit one (it manifests with removal of class main-form). I've tracked this to the controlForms function, and noticed some commented out code - why was that, and is this pull request correct then? (In my case it is).

@agocorona
Copy link
Owner

I did not find a way to handle all the cases, and sometimes the commented code produced undesired results. But I don´t know now how to reproduce the problem. It should be a matter of uncommenting it and running some form examples in demos-blaze, specially the latter ones. But I can not do it now. Currently controlForms only handles the opposite case: when the first form is implicit and the second explicit.

You can make it work if you make explicit the second form with wform $ submitButton "ok"

@BartAdv
Copy link
Contributor Author

BartAdv commented Aug 5, 2014

I might check some - but I did not simply uncommented the code, I just replaced it with analogue code to the one that was there (the commented out used ++, no idea why)

@agocorona
Copy link
Owner

Thanks. The ++ is because it is old code, when the rendering of the widget was defined as a list of renderings.

@BartAdv
Copy link
Contributor Author

BartAdv commented Aug 5, 2014

GenerateForm (only versions without autoRefresh) - cannot prepare group for checkboxes/options, but it doesn't seem to be caused by that change.

@agocorona
Copy link
Owner

The error is reproducibe in mflowdemo.herokuapp.com?

2014-08-05 12:32 GMT+02:00 Bartosz notifications@github.com:

GenerateForm - cannot prepare group for checkboxes/options, but it doesn't
seem to be caused by that change.


Reply to this email directly or view it on GitHub
#52 (comment).

Alberto.

@BartAdv
Copy link
Contributor Author

BartAdv commented Aug 5, 2014

Nope

@BartAdv
Copy link
Contributor Author

BartAdv commented Aug 7, 2014

Aha, I know what it breaks - dynamic widgets end up having 'send' button in different form than the rest of the widget

@agocorona
Copy link
Owner

I found no way to handle all the cases automatically.

2014-08-07 10:23 GMT+02:00 Bartosz notifications@github.com:

Aha, I know what it breaks - dynamic widgets end up having 'send' button
in different form than the rest of the widget


Reply to this email directly or view it on GitHub
#52 (comment).

Alberto.

@BartAdv
Copy link
Contributor Author

BartAdv commented Aug 7, 2014

Yeah, maybe there is no point trying to.

@BartAdv BartAdv closed this Aug 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants