Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Component/s: Resources
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_small importance_medium

      Show
      size_small importance_medium

      Description

      https://issues.apache.org/jira/browse/MFCOMMONS-29

      The features of this ResourceHandler include the following:

      • relative paths between resources (css files referencing images
        without using #resource['..'])
      • caching resources in the client (disabled if ProjectStage == Development)
      • GZIP compression and local cache in tmp dir (disabled if
        ProjectStage == Development)
      • i18n (supporting country code and language).

      In addition, it does NOT support ValueExpressions in resource files
      for performance reasons.

      The most important feature, in my opinion, is how the resource URL is
      built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css

      ... because it permits resources referencing other resources without
      #

      {resource['...']}

      (e.g. css files referencing images or other css
      files). With the standard ResourceHandler this is 1) annoying if you
      have to change the files you get from your designer and 2) a
      performance bottleneck, because resources with ValueExpressions are
      not cached and also regenerated for each request.

      Furthermore, the resource URL contains the locale and thus you have no
      problems with cached resources if a users changes the locale, because
      he/she will get a new URL and thus a new resource (the right one).

        Issue Links

          Activity

          Hide
          Manfred Riem added a comment -

          Setting priority to Critical

          Show
          Manfred Riem added a comment - Setting priority to Critical
          Hide
          Ed Burns added a comment -

          Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

          Show
          Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
          Hide
          Ed Burns added a comment - - edited

          A resource path from Jakob's impl looks like
          "/javax.faces.resource/1.0.0/en_US/css/style.css". Does that 1.0.0
          refer to library version or resource version?

          Here's a clue, from RelativeResourceHandler#132.

          // skip version in url (first part, only there to avoid cache problems on updates)
          final int versionSlash = resourceName.indexOf('/');

          But that still doesn't answer my question. What does the 1.0.0 mean?

          Jakob's ResourceHandler.createResource() allows the entire resourceId to
          be in the "resourceName", which it re-interprets according to its own
          rules if it determines that the library is not a JSF 2.0 style resource
          library.

          JK> The need to have the libraryName configured in
          JK> relative-resources.xml does only exist, because I needed a way to
          JK> enable the RelativeResourceHandler only for certain libraries. This
          JK> would not be necessary if the standard ResourceHandler already uses
          JK> the "relative-mechanism" (for all libraries).

          Ok, let's say we make relative libraries the default for prefix mapped
          applications. If we have a jar in the classpath that contains a library
          that is arranged according to the JSF 2.0 spec for resource libraries,
          we now we need some way to detect that case and use the JSF 2.0 style
          arrangement, right?

          Show
          Ed Burns added a comment - - edited A resource path from Jakob's impl looks like "/javax.faces.resource/1.0.0/en_US/css/style.css". Does that 1.0.0 refer to library version or resource version? Here's a clue, from RelativeResourceHandler#132. // skip version in url (first part, only there to avoid cache problems on updates) final int versionSlash = resourceName.indexOf('/'); But that still doesn't answer my question. What does the 1.0.0 mean? Jakob's ResourceHandler.createResource() allows the entire resourceId to be in the "resourceName", which it re-interprets according to its own rules if it determines that the library is not a JSF 2.0 style resource library. JK> The need to have the libraryName configured in JK> relative-resources.xml does only exist, because I needed a way to JK> enable the RelativeResourceHandler only for certain libraries. This JK> would not be necessary if the standard ResourceHandler already uses JK> the "relative-mechanism" (for all libraries). Ok, let's say we make relative libraries the default for prefix mapped applications. If we have a jar in the classpath that contains a library that is arranged according to the JSF 2.0 spec for resource libraries, we now we need some way to detect that case and use the JSF 2.0 style arrangement, right?
          Hide
          Jakob Korherr added a comment -

          The need to have the libraryName configured in relative-resources.xml does only exist, because I needed a way to enable the RelativeResourceHandler only for certain libraries. This would not be necessary if the standard ResourceHandler already uses the "relative-mechanism" (for all libraries).

          There are many reasons:

          1) Acceptance: There is no other framework (at least which I know of), in which you cannot use relative paths between resources as they would work in the file system. Nearly every IDE supports "resource-exists-checks" in css files with relative paths in the file system, and these IDEs will mark #

          {resource[]}

          url references as errors. Every server (http or servlet container), CDN,... supports relative paths in the URLs like a normal file system, why should JSF do this differently?

          2) Effort: You need quite a lot of time to change a big CSS framework (which you will get from your designers) into a working JSF version. And remember, next day the designer may change something, then you will get a new version of the whole CSS framework, and the work starts again...

          3) Performance: Actually, having ValueExpressions in resource files is not only a performance killer, it also gives the developer the impression as if she could change resource file contents in every request, whereas she really cannot, because the resource will get cached by the browser/proxy.

          I actually would not use the current JSF ResourceHandler because of these points and instead let tomcat (or even weblets) handle my resources, because they both support relative paths like a calm.

          Show
          Jakob Korherr added a comment - The need to have the libraryName configured in relative-resources.xml does only exist, because I needed a way to enable the RelativeResourceHandler only for certain libraries. This would not be necessary if the standard ResourceHandler already uses the "relative-mechanism" (for all libraries). There are many reasons: 1) Acceptance: There is no other framework (at least which I know of), in which you cannot use relative paths between resources as they would work in the file system. Nearly every IDE supports "resource-exists-checks" in css files with relative paths in the file system, and these IDEs will mark # {resource[]} url references as errors. Every server (http or servlet container), CDN,... supports relative paths in the URLs like a normal file system, why should JSF do this differently? 2) Effort: You need quite a lot of time to change a big CSS framework (which you will get from your designers) into a working JSF version. And remember, next day the designer may change something, then you will get a new version of the whole CSS framework, and the work starts again... 3) Performance: Actually, having ValueExpressions in resource files is not only a performance killer, it also gives the developer the impression as if she could change resource file contents in every request, whereas she really cannot, because the resource will get cached by the browser/proxy. I actually would not use the current JSF ResourceHandler because of these points and instead let tomcat (or even weblets) handle my resources, because they both support relative paths like a calm.
          Hide
          Ed Burns added a comment -

          Jakob, what is the main reason for being dissatisfied with this syntax for relative resources?

          css_master.css:

          @import url(#

          {resource['this:layout.css']}

          );

          Is it performance?

          Show
          Ed Burns added a comment - Jakob, what is the main reason for being dissatisfied with this syntax for relative resources? css_master.css: @import url(# {resource['this:layout.css']} ); Is it performance?

            People

            • Assignee:
              Unassigned
              Reporter:
              Ed Burns
            • Votes:
              24 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 5 days Original Estimate - 5 days
                5d
                Remaining:
                Time Spent - 2 hours Remaining Estimate - 5 days
                5d
                Logged:
                Time Spent - 2 hours Remaining Estimate - 5 days
                2h