Announcement Announcement Module
Collapse
No announcement yet.
Bind without validate Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bind without validate

    I've found a usability thing here with pr3/4. My form object exposes an 'occurnaceDate' property. That property is a date object that is initialized on creation. In my FormAction I register a CustomDateEditor in the initBinder method. Unfortunately when I show the view my CustomDateEditor is never used, becuase initBinder is only called during bindAndValidate.

    I tried the bindOnSetupForm route, but that attempts to validate a brand new form object that is of course missing all of its required parameters and yaks.

    So, the question. Is there a 'proper' way to bind on setup, without validating?

  • #2
    I see. Yes, FormAction in general needs some polishing.

    We're working on this now. Stay tuned.

    Keith

    Comment


    • #3
      setupForm() also initializes the binder.

      If for some reason you still need to bind without validating, you can copy some code from http://opensource.atlassian.com/proj...rowse/SPR-1145. (Keith, this bug hasn't yet been re-assigned to you; if you're reworking FormAction, please take a look. They should add a project component to JIRA for SWF...).

      Comment


      • #4
        Is there a usecase for binding AND validation on setupForm?

        Or does just binding make sense?

        Keith

        Comment


        • #5
          Re: Bind without validate

          Originally posted by RayKrueger
          I've found a usability thing here with pr3/4. My form object exposes an 'occurnaceDate' property. That property is a date object that is initialized on creation. In my FormAction I register a CustomDateEditor in the initBinder method. Unfortunately when I show the view my CustomDateEditor is never used, becuase initBinder is only called during bindAndValidate.

          I tried the bindOnSetupForm route, but that attempts to validate a brand new form object that is of course missing all of its required parameters and yaks.

          So, the question. Is there a 'proper' way to bind on setup, without validating?
          Ray,

          You can override onBindAndValidate to check the current state id and return the success event even if validation fails. Peep this:

          Code:
          protected Event onBindAndValidate(RequestContext context, Object formObject, BindException errors) {
                  Event bindValidateEvent = super.onBindAndValidate(context, formObject, errors);
                  String stateId = context.getFlowContext().getCurrentState().getId();
                  if (stateId.equals("setupTheForm"))
                      return success();
                  return bindValidateEvent;
              }
          It's not pretty, but it works.

          -Alex

          Comment


          • #6
            That's exactly what I was thinking. I don't see where bind and validate would be useful really. I'm just one guy though.

            The custom FormAction I'm using here does bindOnSetup using the bind method from SPR-1145.

            If FormAction supported bind on setup, instead of bind and validate on setup, users could create their own validate action to be called in the flow after setupForm. (Provided bindOnSetup is enabled)

            Comment


            • #7
              FormAction in CVS now has these finer-grained invokable action methods:

              setupForm
              bind
              validate
              bindAndValidate
              resetForm

              setupForm has the capability to turn on/off binding using the setupBindingEnabled(context) hook. Even if binding does not occur on setup your property editors will still be registered.

              bindAndValidate has the capability to turn on/off validation via validationEnabled(context) hook.

              In light of this, we've also taken out some of the hook methods like onBind above, for example. These really don't make sense here -- if you need general post processing, simply chain action methods together from your flow definition.

              Erwin and I may release a PR4a but I recommend trying these out if you have CVS access ASAP!

              Keith

              Comment


              • #8
                As soon as anonymous cvs is updated I'm all over it :P

                Thanks Keith!
                -Ray

                Comment


                • #9
                  I tried out the new changes but, there appears to be an issue in the latest FormAction (v1.21)...

                  Line 493:
                  Code:
                  if (binder.getAllowedFields() != null || binder.getAllowedFields().length > 0) {
                  That should be an && check, it tosses a NullPointerException right now.

                  Comment


                  • #10
                    DOH, one more thing...

                    org.springframework.webflow.Event needs to implement equals and hashCode.

                    Then we could simply do success().equals(success()); Right now you have to do success().getId().equals(success().getId()); Unfortunately that can lead to bugs pretty easy.

                    For instance :P Line 463 of FormAction (v1.21)
                    Code:
                    if (success().equals(result.getId())) {
                    The above code is never true.

                    Comment


                    • #11
                      Please also change Event bind(RequestContext context) from private to public.

                      Comment


                      • #12
                        You guys catching my intermediate commits :-)

                        Done and done.

                        One concern about Event: should it implement equals and hashCode? There is an argument that says no two events are equal: they have differerent time stamps. They're id's might be equal... in any case the success().equals(result.getId()) was a bug, it should've been (and is now) SUCCESS_EVENT_ID.equals(result.getId()).

                        Keith

                        Comment


                        • #13
                          Hmm, yeah, good point on the Event. Just so long as it's well documented that getId().equals(...) should be used for comparing event types.

                          Comment


                          • #14
                            I have a few more problems with ActionForm (in cvs). Please excuse me if this is a work in progress and I'm reporting known problems. I had problems with PR4 and decided to try a build from cvs as was suggested elsewhere in this forum.

                            1. Bind and validate no longer expose errors.
                            2. I notice that if bind fails, validate is not attempted. This is a change from pr3. I think it's a better experience for the user if we report all form errors up front, rather than having the user fix the binding errors, and then be presented with the validation errors.
                            3. My custom property editors are not being picked up as before. My flow invokes setupForm as its first action.

                            Comment


                            • #15
                              Okay,

                              Erwin and I have completed refactoring of FormAction and have checked in an exhaustive unit test.

                              Please give the latest in CVS a try (keep in mind the delay in anon CVS access).

                              Once we're happy, we'll look at cutting a PR5 to take care of some of this issue, the JDK 1.3 compatability issue, and general documentation bugs.

                              Keith

                              Comment

                              Working...
                              X