Tapestry 5
  1. Tapestry 5
  2. TAP5-51

"Parents before Child" concept for Component Rendering does not allow different rendering in subclasses

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      I subclassed GridPager ( public class MyGridPager extends GridPager) to implement another pager visualisation.
      After creating a MyGrid (public class MyGrid extends Grid) which uses MyGridPager and copying Grid,tml to MyGrig.tml ist was ready to test.

      Start.tml:
      <t:mygrid source="tl" row="treffer" rowsPerPage="5">
      <t:parameter name="regnrcell">
      <t:pagelink page="marke2" > $

      {treffer.regnr}

      </t:pagelink>
      </t:parameter>
      </t:mygrid>

      It runs fine - but I got the "old" ,default Visualiation AND the new one. It is a result of the "Parents before Child" concept .
      First the Parent creates its visualisatrion the my Child createy its new visualisation.

      Subclasses can not decide of they want to call the implemetation of their parent or not.

      Why is this implemented like this?
      Why call parent implemtation at all, the child could do this explicit by calling super.XXX.( I know Annotations may make this more complex)

      Can you help ?

        Issue Links

          Activity

          Fritz Pröbstle created issue -
          Hide
          Howard M. Lewis Ship added a comment -

          There are complex issues at foot here, and there may not be any single solution that meets all needs in all cases.

          The super approach is not valid: the super class methods may be private, or have different parameters or return types.

          Show
          Howard M. Lewis Ship added a comment - There are complex issues at foot here, and there may not be any single solution that meets all needs in all cases. The super approach is not valid: the super class methods may be private, or have different parameters or return types.
          Hide
          Howard M. Lewis Ship added a comment -

          My approach here will be that if the child class overrides a method of the parent, then the overridden method will be invoked only by the parent class, not the subclass.

          Show
          Howard M. Lewis Ship added a comment - My approach here will be that if the child class overrides a method of the parent, then the overridden method will be invoked only by the parent class, not the subclass.
          Howard M. Lewis Ship made changes -
          Field Original Value New Value
          Assignee Howard M. Lewis Ship [ hlship ]
          Howard M. Lewis Ship made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Howard M. Lewis Ship committed 664538 (17 files)
          Reviews: none
          Old issue: TAPESTRY-2311

          TAPESTRY-2311: "Parents before Child" concept for Component Rendering does not allow different rendering in subclasses

          tapestry trunk
          Howard M. Lewis Ship made changes -
          Fix Version/s 5.0.13 [ 12313205 ]
          Status In Progress [ 3 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Hide
          Fritz Pröbstle added a comment - - edited

          The override functionality works fine if all classes base and subclass(es) are in the same package-then
          the overriden function is called for subclass only.

          If base and subclasses are in different packages only the base class function is called. ( It seams as if tapestry did not "see" the overwritten one.

          This really seams to be the problem, because if you
          specify the function to be "protected" (at least) tapestry can "see" it and calls the correct one.

          This workaound can be done id source is available for the base class(es) and does not work if I want to subclass
          core-components.( And naturally this is doen in another package, so this error prevents my to use the new Overridíng feature)

          Show
          Fritz Pröbstle added a comment - - edited The override functionality works fine if all classes base and subclass(es) are in the same package-then the overriden function is called for subclass only. If base and subclasses are in different packages only the base class function is called. ( It seams as if tapestry did not "see" the overwritten one. This really seams to be the problem, because if you specify the function to be "protected" (at least) tapestry can "see" it and calls the correct one. This workaound can be done id source is available for the base class(es) and does not work if I want to subclass core-components.( And naturally this is doen in another package, so this error prevents my to use the new Overridíng feature)
          Fritz Pröbstle made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          Resolution Fixed [ 1 ]
          Howard M. Lewis Ship made changes -
          Assignee Howard M. Lewis Ship [ hlship ]
          Howard M. Lewis Ship made changes -
          Project Tapestry [ 10573 ] Tapestry 5 [ 12310833 ]
          Affects Version/s 5.0.11 [ 12312968 ]
          Fix Version/s 5.0.13 [ 12313205 ]
          Component/s tapestry-core [ 12311285 ]
          Key TAPESTRY-2311 TAP5-51
          Hide
          Howard M. Lewis Ship added a comment -

          Still don't think there's a bug here, and your comment about different packages ... are you sure the overridden methods are protected or public?

          Show
          Howard M. Lewis Ship added a comment - Still don't think there's a bug here, and your comment about different packages ... are you sure the overridden methods are protected or public?
          Howard M. Lewis Ship made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Invalid [ 6 ]
          Assignee Howard M. Lewis Ship [ hlship ]
          Alexander Gavrilov made changes -
          Link This issue is blocked by TAP5-1284 [ TAP5-1284 ]
          Alexander Gavrilov made changes -
          Link This issue is blocked by TAP5-1284 [ TAP5-1284 ]
          Alexander Gavrilov made changes -
          Link This issue is related to TAP5-1284 [ TAP5-1284 ]

            People

            • Assignee:
              Howard M. Lewis Ship
              Reporter:
              Fritz Pröbstle
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development