Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2 Sprint 11 B
    • Component/s: Navigation
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      809
    • Status Whiteboard:
      Hide

      size_large importance_medium

      Show
      size_large importance_medium
    • Tags:

      Description

      In Facelets 1.x, it was possible to implement load views from external locations (such as the class path,
      or a repository) by providing a ResourceResolver implementation.

      The ResourceResolver is also present in JSF 2, so this is still possible. However, there is a new
      requirement. Implicit navigation calls ExternalContext.getResource() to determine whether a view id
      corresponds to a physical resource. If ExternalContext.getResource() returns a non-null URL, implicit
      navigation to the view id is allowed.

      This contract is not ideal, as:

      1. It is non-obvious.
      2. It requires hooking into multiple locations.
      3. It makes it difficult to distinguish between requests for view ids vs. other types of resources.

      Regarding #3… ExternalContext.getResource() may be used for all sorts of resources. In our case we
      only want to search our external repositories when a view id is requested, but not, say, when someone
      calls getResource() to load some other type of file (eg. a style sheet).

      We need to introduce a cleaner contract that simplifies the responsibilities for custom view loading
      implementations.

        Issue Links

          Activity

          aschwart created issue -
          kenaiadmin made changes -
          Field Original Value New Value
          issue.field.bugzillaimportkey 809 20414
          Ed Burns made changes -
          Comment [ Empirically speaking, I'm finding that the resource request for javax.faces jsf.js is *not* causing ExternalContext.getResource() to be called. Therefore, I refute your assertion that

            Regarding #3… ExternalContext.getResource() may be used for all sorts of resources. In
            our case we
            only want to search our external repositories when a view id is requested, but not, say,
            when someone
            calls getResource() to load some other type of file (eg. a style sheet).

          ]
          Ed Burns made changes -
          Remaining Estimate 0 minutes [ 0 ]
          Time Spent 2 hours [ 7200 ]
          Ed Burns made changes -
          lamine_ba made changes -
          Comment [ if we treat a view like a resource, The external context cannot be the only resolver in the case of :

          1) I have additionnal repositories
          2) I'm scaling in my JSF application and want to avoid the resources duplication by having an external and central repository.
          ....
          ....

          One solution could be to have a chain of resource resolvers where the external context will be the last.

          {code}
          public interface ResourceResolver {
              Resource getResource(String location);
          }
          {code}

          this interface is similar to Spring ResourceLoader (http://static.springsource.org/spring/docs/2.5.x/reference/resources.html)

          Let's try to find the elements that could be in the chain.

          - the External Context

          {code}
          public abstract class ExternalContext implements ResourceResolver {
          public Resource getResource(String location) {
                }
          }
          {code}

          - ModuleManager ( Lay the groundwork for application modules – a set of views, images, stylesheets, etc., inside of a JAR file)

          Issue : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532

          {code}
          public class ModuleManager extends PluginManager<Module> {
          }
          {code}

          - Multi-templating System : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971

          {code}
          public class TemplateManager extends PluginManager<Template> {
          }
          {code}

          Plugin System : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-970

          {code}
          public abstract class PluginManager<T extends Plugin> implements ResourceResolver {

           public Resource getResource(String name) {
          return folder.getDocument(name);
               }
          }
          {code}

          The ResourceHandler could be the entry point to add a new resolver and to resolve a Resource. ]
          lamine_ba made changes -
          Comment [ Yes Kito it'd make sense to unify the resource-handling mechanism.


          (3) Allow views (or sets of views) to be versioned and localized
          (4) Lay the groundwork for application modules – a set of views, images, stylesheets, etc., inside of a JAR file.


          Every JSF application has a front end and a back end. Once we have this issue resolved http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532, One can create some modules for our back end to ease the development and the management of a JSF application. We don't need anymore eclipse, netbeans to have our tools.


          (1) Provide the ability to load Facelet views from a JAR without writing a custom class.

          Thus I can bring default facelets views you can customize if they don't meet your needs



          (2) Provide a single entry point for customizing resource resolution and view resolution.

          A view is nothing more than a Resource, why do we have this mismatch? If resources are stored in different locations, it is fairly impossible to aggregate and resolve them if we don't have a single entry point where we can reach the other points.
          ]
          lamine_ba made changes -
          Comment [ Related issues:

          The Resource class should be an interface : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-986 ]
          lamine_ba made changes -
          Comment [ Related issues:

          Need method to map viewId to resource path : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-719 ]
          Ed Burns made changes -
          Assignee rogerk [ rogerk ] Ed Burns [ edburns ]
          Ed Burns made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 2.2 Sprint 11 B [ 15573 ]
          Fix Version/s 2.2 [ 10403 ]
          Resolution Fixed [ 1 ]
          Manfred Riem made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Ed Burns
              Reporter:
              aschwart
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 2 hours
                2h