Wicket
  1. Wicket
  2. WICKET-3742

BaseWicketTester: provide startComponentInPage with componentn parameter but without pageMarkup

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5-RC5
    • Fix Version/s: 1.5-RC5
    • Component/s: wicket
    • Labels:
      None

      Description

      BaseWicketTester have a startComponentInPage(componentClass) which just calls startComponentInPage(componentClass, pageMarkup) with pageMarkup == null.

      There is also a startComponentInPage with component as parameter (instead of componentClass), but only one method, which want a pageMarkup parameter. Could you please provide also a overloaded method for startComponentInPage without pageMarkup parameter? Like...

      public final <C extends Component> C startComponentInPage(final C component)

      { return startComponentInPage(component, null); }

      Thanks.

        Issue Links

        There are no Sub-Tasks for this issue.

          Activity

          Hide
          Martin Grigorov added a comment -

          Currently there are 5 startComponentXYZ() methods. Maybe it is just me but I think that WicketTester API is big even now.

          Show
          Martin Grigorov added a comment - Currently there are 5 startComponentXYZ() methods. Maybe it is just me but I think that WicketTester API is big even now.
          Hide
          manthos added a comment -

          Ok, currently startComponentInPage can be used with a componentClass or with a component. But for what reason, one of them can be called also without a pageMarkup parameter but the other one not?

          I agree that WicketTester API is big even, but IMO usability/flexibility is more important than count of methods xyz (mainly if we talk about overloaded methods). I don't see why a method have a overloaded version for one case but not for the other.
          Just created this issue to improve functionality of BaseWicketTester. If you don't want to include this method feel free to 'WontFix'. I don't have any problem to call startComponentInPage with null parameter... Still great to work with WicketTester.

          Show
          manthos added a comment - Ok, currently startComponentInPage can be used with a componentClass or with a component. But for what reason, one of them can be called also without a pageMarkup parameter but the other one not? I agree that WicketTester API is big even, but IMO usability/flexibility is more important than count of methods xyz (mainly if we talk about overloaded methods). I don't see why a method have a overloaded version for one case but not for the other. Just created this issue to improve functionality of BaseWicketTester. If you don't want to include this method feel free to 'WontFix'. I don't have any problem to call startComponentInPage with null parameter... Still great to work with WicketTester.
          Hide
          Martin Grigorov added a comment -

          Agree. It doesn't look nice now.
          I'd either add yet another (overloaded) method or remove the one that accepts just the component's class.

          Having 50+ public methods confuses the users. The IDE suggestion dropdown has many entries and it is hard to find what you need.
          I was thinking about introducing "namespace objects". Something like : tester.start().page(...), tester.start().componentInPage(...), tester.assert().isvisible(..), tester.assert().model(...), tester.execute().link(...), etc.
          All of these "namespace methods" will do something like :
          BaseWicketTester#assert()

          { return Assert(this)}

          ;
          BaseWicketTester.Assert#isVisible

          {tester.assertIsVisible(x)}

          and BaseWicketTester#assertIsVisible will be made deprecated and either removed in later version or made private (hidden).

          This way the IDE will suggest only #start(), #execute(), #assert(), etc. initially. Then when the user selects one of them the IDE will suggest only the methods related to this "namespace".

          But maybe it is too late for Wicket 1.5.

          Show
          Martin Grigorov added a comment - Agree. It doesn't look nice now. I'd either add yet another (overloaded) method or remove the one that accepts just the component's class. Having 50+ public methods confuses the users. The IDE suggestion dropdown has many entries and it is hard to find what you need. I was thinking about introducing "namespace objects". Something like : tester.start().page(...), tester.start().componentInPage(...), tester.assert().isvisible(..), tester.assert().model(...), tester.execute().link(...), etc. All of these "namespace methods" will do something like : BaseWicketTester#assert() { return Assert(this)} ; BaseWicketTester.Assert#isVisible {tester.assertIsVisible(x)} and BaseWicketTester#assertIsVisible will be made deprecated and either removed in later version or made private (hidden). This way the IDE will suggest only #start(), #execute(), #assert(), etc. initially. Then when the user selects one of them the IDE will suggest only the methods related to this "namespace". But maybe it is too late for Wicket 1.5.
          Hide
          manthos added a comment -

          Agree. Add another overloaded or remove overloaded. This would make startComponentInPage straightforward.

          I also like the approach of "namespace objects".

          Show
          manthos added a comment - Agree. Add another overloaded or remove overloaded. This would make startComponentInPage straightforward. I also like the approach of "namespace objects".
          Hide
          Martin Grigorov added a comment -

          The new method is added with r1128173.

          Show
          Martin Grigorov added a comment - The new method is added with r1128173.

            People

            • Assignee:
              Martin Grigorov
              Reporter:
              manthos
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development