Tapestry
  1. Tapestry
  2. TAPESTRY-737

Support custom PageRenderSupportImpl in component Body

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.1
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      4b12

      Description

      Make it possible to use a custom PageRenderSupport implementation in Body, eg. by using a pageRenderSupport parameter.

      BR,
      Norbi

      1. patch.txt
        4 kB
        Jesse Kuhnert

        Activity

        Hide
        Ron Piterman added a comment -

        Just curious, maybe howard will also be: usecase?

        Show
        Ron Piterman added a comment - Just curious, maybe howard will also be: usecase?
        Hide
        Norbert Sándor added a comment -

        I have a complex page where I render large component groups conditionally. The components should be rendered because of side effects of their rendering process but the output is not written to the client. It is achieved using NullWriter if certain conditions met. It would work but the scripts generated by these components are rendered as normal while they should be ignored.

        Now I solve it by subclassing Body and doing the checks in the addXScript methods. A better word is copypasting, because Body stores the pagesupportimpl as a private member so subclassing is not really supported.

        It is not an important feature (as you see I can solve it using a custom component) but maybe someone else may have such comlex scenario and extensibility is always good in case of framework components I think...
        Maybe it was a bad idea to make it a parameter, it would be better as a protected method.

        BR,
        Norbi

        Show
        Norbert Sándor added a comment - I have a complex page where I render large component groups conditionally. The components should be rendered because of side effects of their rendering process but the output is not written to the client. It is achieved using NullWriter if certain conditions met. It would work but the scripts generated by these components are rendered as normal while they should be ignored. Now I solve it by subclassing Body and doing the checks in the addXScript methods. A better word is copypasting, because Body stores the pagesupportimpl as a private member so subclassing is not really supported. It is not an important feature (as you see I can solve it using a custom component) but maybe someone else may have such comlex scenario and extensibility is always good in case of framework components I think... Maybe it was a bad idea to make it a parameter, it would be better as a protected method. BR, Norbi
        Hide
        Jesse Kuhnert added a comment -

        I would say that what I'm doing with this scenerio is probably not the nicest thing in the world, but I override this behaviour by using the EnhancementWorkers hivemind tapestry worker chain to contribute my own custom enhancements to the Body component. One of which is overriding writing the javascript portions of the response. It's not pretty, but getting at the private member of any class is always possible via reflection.

        If this has anything to do with tacos I'd love to hear more specifics about a problem you are trying to solve so that I can change the framework to better support your particular needs.

        Show
        Jesse Kuhnert added a comment - I would say that what I'm doing with this scenerio is probably not the nicest thing in the world, but I override this behaviour by using the EnhancementWorkers hivemind tapestry worker chain to contribute my own custom enhancements to the Body component. One of which is overriding writing the javascript portions of the response. It's not pretty, but getting at the private member of any class is always possible via reflection. If this has anything to do with tacos I'd love to hear more specifics about a problem you are trying to solve so that I can change the framework to better support your particular needs.
        Hide
        Jesse Kuhnert added a comment -

        Ummmm...I actually need something similar to this now that I think of it.

        Can TapestryUtils.storeUniqueAttribute be changed to not throw an IllegalStateException if there is an existing object there already? It could instead return a boolean indicating whether or not it was able to successfully store the value. I did a reference check on the method and found nothing besides the Body or Portlet stuff that interacts with this. Nothing seems to rely on this being a failure.

        This would allow people to provide their own PageRenderSupport implementations.

        Show
        Jesse Kuhnert added a comment - Ummmm...I actually need something similar to this now that I think of it. Can TapestryUtils.storeUniqueAttribute be changed to not throw an IllegalStateException if there is an existing object there already? It could instead return a boolean indicating whether or not it was able to successfully store the value. I did a reference check on the method and found nothing besides the Body or Portlet stuff that interacts with this. Nothing seems to rely on this being a failure. This would allow people to provide their own PageRenderSupport implementations.
        Hide
        Norbert Sándor added a comment -

        This seems to be a simple and good solution, as I see...

        Show
        Norbert Sándor added a comment - This seems to be a simple and good solution, as I see...
        Hide
        Jesse Kuhnert added a comment -

        Ok I think this patch would do it. I'll still need to create my own script processor, but this does at least allow a certain level of control. Unit tests/javadoc/etc were updated as well. Seems like a minimal impact sort of change as this api appears to be a little protected.

        Show
        Jesse Kuhnert added a comment - Ok I think this patch would do it. I'll still need to create my own script processor, but this does at least allow a certain level of control. Unit tests/javadoc/etc were updated as well. Seems like a minimal impact sort of change as this api appears to be a little protected.
        Hide
        Jesse Kuhnert added a comment -

        This has now been implemented by the new ResponseRenderer configuration points.

        Show
        Jesse Kuhnert added a comment - This has now been implemented by the new ResponseRenderer configuration points.

          People

          • Assignee:
            Unassigned
            Reporter:
            Norbert Sándor
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development