Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: Facelets/VDL
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      781
    • Status Whiteboard:
      Hide

      size_large importance_medium

      Show
      size_large importance_medium

      Description

      This message is on behalf of Lewis Gass.

      I am writing in relation to a particular use case which reveals that the
      current JSF 2.0 public API is defficient. This is in relation the open
      source project Gracelets (http://gracelets.sourceforge.net/) and the new
      effort to integrate JSF 2.0 with Groovy. In order for people to use Groovy
      as an alternative View Langauge they need
      to have access to the all the Facelets tag libraries and participate in the
      Templating framework that Facelets provides. Much of this is tied to the
      TagLibrary and
      TemplateClient API's. Before, with JSF 1.2, there was a single Facelets
      "API" and/or implementation. So integrating with it was much simpler, as is
      shown by previous Gracelets
      versions. With JSF 2.0, part of the Facelets library was divided into public
      API and another as JSF 2.0 specific implementation.

      However, basic concepts such as Templating (TemplateClient and
      TemplateManager) are not considered public API, which means that a
      technology such as Gracelets
      must rely on a per JSF implementation integration library which is volatile
      in nature. The FaceletContext class is public API, but implementations are
      not required to support
      third party implementations of such, and there is no standard way to access
      the TagLibrary used by facelets so that third part View Languages can
      harness them.

      Thus this message has the purpose of requesting such parts of the old
      Facelets library, namely, the TagLibrary, TemplateClient and the related
      FaceletContext methods (popClient(),
      pushClient(), extendClient() and applyDefinition()) to be part of the public
      JSF 2.0 API, while at the same time requiring JSF 2.0 implementors to
      support third party implementations
      of the same classes/API's.

      Respectfully,
      Lewis Gass
      Gracelets Coder
      sestechllc@gmail.com

        Activity

        lu4242 created issue -
        Hide
        lu4242 added a comment -

        Comments from this discussion: [jsr-314-open]
        javax.faces.view.facelets.ResourceResolver cannot be fully overriden

        Checking this issue on myfaces:

        https://issues.apache.org/jira/browse/MYFACES-2628

        It was notice there is a way to override the default ResourceResolver, used to
        load facelets templates, but the algorithm related to ViewHandler (spec pdf
        section 7.5.2) says that if the physical resource exists with the name
        requestViewId let that value be viewId, otherwise return null. So, if some user
        try to load templates from other sources, the ViewHandler just will not work.

        The problem is there is no standard way to retrieve the current ResourceResolver
        object, so the ViewHandler just can't find them. In myfaces, this one is
        instantiated on facelets vdl object, when it is initialized.

        One idea to solve this one could be expose this object through vdl interface
        (maybe a public method called getResourceResolver()?).

        Since this issue is related to other ones that requires expose facelets api
        objects, I'll not create an issue on the spec jira, but if it is necessary I can
        create it.

        Show
        lu4242 added a comment - Comments from this discussion: [jsr-314-open] javax.faces.view.facelets.ResourceResolver cannot be fully overriden Checking this issue on myfaces: https://issues.apache.org/jira/browse/MYFACES-2628 It was notice there is a way to override the default ResourceResolver, used to load facelets templates, but the algorithm related to ViewHandler (spec pdf section 7.5.2) says that if the physical resource exists with the name requestViewId let that value be viewId, otherwise return null. So, if some user try to load templates from other sources, the ViewHandler just will not work. The problem is there is no standard way to retrieve the current ResourceResolver object, so the ViewHandler just can't find them. In myfaces, this one is instantiated on facelets vdl object, when it is initialized. One idea to solve this one could be expose this object through vdl interface (maybe a public method called getResourceResolver()?). Since this issue is related to other ones that requires expose facelets api objects, I'll not create an issue on the spec jira, but if it is necessary I can create it.
        Hide
        Ed Burns added a comment -

        Move to 2.1

        Show
        Ed Burns added a comment - Move to 2.1
        Hide
        Ed Burns added a comment -

        triage

        Show
        Ed Burns added a comment - triage
        Hide
        Ed Burns added a comment -

        edburns

        Show
        Ed Burns added a comment - edburns
        Hide
        Ed Burns added a comment -

        Change target milestone.

        Show
        Ed Burns added a comment - Change target milestone.
        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        kenaiadmin made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 781 20386
        Ed Burns made changes -
        Assignee Ed Burns [ edburns ]
        Hide
        Ed Burns added a comment -

        We are considering extracting Facelets out of JSF for use outside of JSF as well as inside. This would have to be addressed in that case.

        Show
        Ed Burns added a comment - We are considering extracting Facelets out of JSF for use outside of JSF as well as inside. This would have to be addressed in that case.
        Ed Burns made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Won't Fix [ 2 ]
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out
        Manfred Riem made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: