Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7DR#2
    • Fix Version/s: 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      All
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial, Compatibility/Configuration

      Description

      In our icefaces.jar, we have a faces-config.xml which stomps over the regular renderers for the standard h: components. This means that when you have an application with mixed ICEfaces and non-ICEfaces pages, there's limitations where you have to use just-ice.jar, and use ice: component in the ICEfaces pages and h: components in the non-ICEfaces pages. It probably also limits the ways we can go between the two types of pages.

      What would be preferable is if we programmatically overrode these relationships, maintaining the defaults, so that depending on the context of the request, we could return either the stock renderers or the ICEfaces D2D renderers, all within the same application.

      Technically, all of the encode and decode methods make use of UIComponentBase.getRenderer(FacesContext) to find the Renderer. It gets the RenderKit from the FacesContext, and asks it for the Renderer. We could employ several approaches:

      A) Have our BridgeFacesContext return a different RenderKit, that would return the ICEfaces Renderers, leaving the regular FacesContext to return the regular RenderKit with the stock Renderers

      B) Capture the stock renderers, and wrap them into proxy renderers, which will use the stock of ICEfaces ones appropriately

      Care should be taken to make this work with our ICE-2309 efforts.

        Issue Links

          Activity

          Hide
          Mark Collette added a comment -

          Given the functionality in ICE-3543, we should be able to just flip between RenderKits, when we're on different types of pages, using the ICEfacesRenderKit one for ICEfaces pages, and the HTML_BASIC for non-ICEfaces pages.

          It might be as simple as modifying how we set the UIViewRoot's renderKitId, potentially by overriding ViewHandler.calculateRenderKitId(FacesContext).

          Show
          Mark Collette added a comment - Given the functionality in ICE-3543, we should be able to just flip between RenderKits, when we're on different types of pages, using the ICEfacesRenderKit one for ICEfaces pages, and the HTML_BASIC for non-ICEfaces pages. It might be as simple as modifying how we set the UIViewRoot's renderKitId, potentially by overriding ViewHandler.calculateRenderKitId(FacesContext).
          Hide
          Mark Collette added a comment -

          We need to make sure that we're handling the renderKitId as we should. There are methods in the JSF 1.2 code, in ViewHandlerImpl and FacesContextImpl that deal with renderKitId, defaultRenderKitId, and RenderKit, that we should make sure our D2DViewHandler and BridgeFacesContext do equivalently. Those have to be tested with state saving turned off, and turned on.

          Show
          Mark Collette added a comment - We need to make sure that we're handling the renderKitId as we should. There are methods in the JSF 1.2 code, in ViewHandlerImpl and FacesContextImpl that deal with renderKitId, defaultRenderKitId, and RenderKit, that we should make sure our D2DViewHandler and BridgeFacesContext do equivalently. Those have to be tested with state saving turned off, and turned on.
          Hide
          Mark Collette added a comment -

          One this is in place, then we can remove the default-renderkit-id entry from icefaces.jar's faces-config.xml. This will have the side-effect of simplifying the design-time scenario, which will go back to using the HTML_BASIC RenderKit, that doesn't include our h: D2D Renderers.

          Show
          Mark Collette added a comment - One this is in place, then we can remove the default-renderkit-id entry from icefaces.jar's faces-config.xml. This will have the side-effect of simplifying the design-time scenario, which will go back to using the HTML_BASIC RenderKit, that doesn't include our h: D2D Renderers.
          Hide
          Mark Collette added a comment -

          ICEfaces 2 doesn't override the default renderers, and we can control on a page by page basis if ICEfaces is being used.

          Show
          Mark Collette added a comment - ICEfaces 2 doesn't override the default renderers, and we can control on a page by page basis if ICEfaces is being used.

            People

            • Assignee:
              Unassigned
              Reporter:
              Mark Collette
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: