Wicket
  1. Wicket
  2. WICKET-1622

expose the IItemFactory in RefreshingView

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.3.3
    • Fix Version/s: 1.3.5, 1.4-M3
    • Component/s: wicket
    • Labels:
      None

      Description

      I have modified the RefreshingView to expose the IItemFactory to facilitate dynamic row additions using the IItemFactory impl that was used to create the original rows onPopulate. This allows code to use the protected methods of RefreshingView (newChildId(), newItem(), populateItem()) that they would normally have access to as well as promote code resue for this activity.

        Activity

        Hide
        Chuck Deal added a comment -

        This is the patch the impls the proposed feature

        Show
        Chuck Deal added a comment - This is the patch the impls the proposed feature
        Hide
        Igor Vaynberg added a comment -

        could you please explain your usecase in more detai...

        Show
        Igor Vaynberg added a comment - could you please explain your usecase in more detai...
        Hide
        Chuck Deal added a comment - - edited

        I have previously used the DataTable and I am now using the inmethod-grid. Both are based upon (or use) the RefreshingView. My interface allows the user the ability to add lines to the grid. In order to avoid a screen refresh, I use ajax to initiate the addition of a grid row. By using the same IItemFactory that was used to create the initial rows I can minimize the extra code I have to write to inject a row into the grid. I even want to avoid a complete repaint of the table, because that could be expensive as well.

        I suppose an alternate to refactoring the IITemFactory our would be to expose the methods that it uses (newChildId(), newItem(), populateItem()), it just seemed that exposing that object would easier and it felt like it had better continutiy of thought to use the same exact code to introduce the new row as was used for the initial dataset.

        The use case:
        The user is presented with a DataTable\inmethod-grid. The grid is designed to reuse the item models. The are also presented with a button that can be used to add an "empty" row to the grid. I my cases, the data uis backed by a database.

        Show
        Chuck Deal added a comment - - edited I have previously used the DataTable and I am now using the inmethod-grid. Both are based upon (or use) the RefreshingView. My interface allows the user the ability to add lines to the grid. In order to avoid a screen refresh, I use ajax to initiate the addition of a grid row. By using the same IItemFactory that was used to create the initial rows I can minimize the extra code I have to write to inject a row into the grid. I even want to avoid a complete repaint of the table, because that could be expensive as well. I suppose an alternate to refactoring the IITemFactory our would be to expose the methods that it uses (newChildId(), newItem(), populateItem()), it just seemed that exposing that object would easier and it felt like it had better continutiy of thought to use the same exact code to introduce the new row as was used for the initial dataset. The use case: The user is presented with a DataTable\inmethod-grid. The grid is designed to reuse the item models. The are also presented with a button that can be used to add an "empty" row to the grid. I my cases, the data uis backed by a database.

          People

          • Assignee:
            Igor Vaynberg
            Reporter:
            Chuck Deal
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development