javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-890

Give the ability to change the scope of <f:loadBundle> to ease its use in composites.

    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: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      890
    • Status Whiteboard:
      Hide

      size_medium importance_small

      Show
      size_medium importance_small

      Description

      When you have a page using these composites:
      <myTools:a/>
      <myTools:b/>
      <myTools:c/>

      and that these composites use a resource bundle by the mean of <f:loadBundle>
      for their own work, you have to take care of using a unique variable for each of
      them.

      If you attempt to ease your coding by using the same variable each time in all
      your composites, such as here (using x):
      <html xmlns="http://www.w3.org/1999/xhtml" [...]>
      </cc:interface/>

      <cc:implementation>
      <f:loadBundle basename="myWork_a" var="x" />
      ...

      Then <myTools:a/>, <myTools:b/>, and <myTools:c/> will use the same bundle,
      whatever their own basename is saying. (I don't remember if only the basename of
      the myWork_a bundle will be used or only myWork_c).

      Then, we have to find unique variables one to ensure our composite won't have
      bundle variables that could collide. Like:
      <f:loadBundle basename="myWork_a" var="xa" /> for component a,
      <f:loadBundle basename="myWork_b" var="xb" /> for component b,
      <f:loadBundle basename="myWork_c" var="xc" /> for component c.

      and of course, it's a bit boring. The problem comes from <f:loadBundle> that has
      a request scope, I think. Can something be done to allow it having only the
      strict composite scope (= no scope at all?).

      Regards,

      Grunt.

        Activity

        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        rogerk added a comment -

        triage

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

        <f:loadBundle> is not the recommended way to perform I18N in JSF. Instead, use application level config in the faces-config.xml.

        Show
        Ed Burns added a comment - <f:loadBundle> is not the recommended way to perform I18N in JSF. Instead, use application level config in the faces-config.xml.
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

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

            Dates

            • Created:
              Updated:
              Resolved: