Tapestry 5
  1. Tapestry 5
  2. TAP5-266

In a conflict between a render phase annotation and the naming convention, the explicit annotation should win

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.0.15
    • Fix Version/s: 5.2.0
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      If i have a method like this:

      @AfterRender
      void beginRender()
      {
      }

      it actually gets executed twice. Once during AfterRender and once during BeginRender. Although i agree that is bad coding it can cause some confusion and make it hard to diagnose.

      In my opinion there should be either an error thrown by Tapestry in this situation or it should just ignore the method name when a render phase annotation is present.

      Also, i didn't try if this also happens for component events.

        Activity

        Hide
        Howard M. Lewis Ship added a comment -

        This is doable, it's just a matter of significantly reorganizing the way we generate the invocations of the render phase methods. We really need to be able to match methods to phases all at once, to ensure that each method is slotted to only one phase (AfterRender for the example in the issue). Currently we do the BeginRender processing, then later the AfterRender processing, and the method gets slotted into each.

        Show
        Howard M. Lewis Ship added a comment - This is doable, it's just a matter of significantly reorganizing the way we generate the invocations of the render phase methods. We really need to be able to match methods to phases all at once, to ensure that each method is slotted to only one phase (AfterRender for the example in the issue). Currently we do the BeginRender processing, then later the AfterRender processing, and the method gets slotted into each.
        Hide
        Howard M. Lewis Ship added a comment -

        A side benefit is that all render phase methods would be handled by a single worker which might boost performance some minute amount.

        Show
        Howard M. Lewis Ship added a comment - A side benefit is that all render phase methods would be handled by a single worker which might boost performance some minute amount.
        Hide
        Howard M. Lewis Ship added a comment -

        I only fixed this for render phase events; I may need to apply the same technique to life cycle events. I don't think this will affect event handler methods, but I'm not sure.

        Show
        Howard M. Lewis Ship added a comment - I only fixed this for render phase events; I may need to apply the same technique to life cycle events. I don't think this will affect event handler methods, but I'm not sure.

          People

          • Assignee:
            Howard M. Lewis Ship
            Reporter:
            Hugo Palma
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development