Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: Components/Renderers
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      316
    • Status Whiteboard:
      Hide

      EGTop5 effort_hard cat2 frame size_large importance_medium

      Show
      EGTop5 effort_hard cat2 frame size_large importance_medium

      Description

      Provide support for skinning:

      • Easy customizable theme/skin API. Skinability Framework, that
        includes Skin parameters API, dynamically generated CSS and Images
        using Skin parameters (related to Resource Framework), easy use of
        Skin parameters from pages and Components.

        Issue Links

          Activity

          Hide
          lamine_ba added a comment - - edited

          I'm not a big fan of components libraries skinning. They are just making the job of a web designer more harder. After having defined the structure of his web interface, a web designer from a clean state will think about how to stylize the HMTL elements (a, h1, div, and so forth...) and not how to stylize your components. What is the finality of an UIComponent? isn't it to render HTML content? Thus providing a default and general css could be a good answer to this problem and my multi-templating feature another one because each template will come with its own css files to make an application change its look and feel. But are these solutions enough in the perspective to have any single UIComponent available in the JSF ecosystem to be customizable with css? wow, how many style classes should we remember in this case? too much for my little head thus I'm only with you if you find conventions at first

          Show
          lamine_ba added a comment - - edited I'm not a big fan of components libraries skinning. They are just making the job of a web designer more harder. After having defined the structure of his web interface, a web designer from a clean state will think about how to stylize the HMTL elements (a, h1, div, and so forth...) and not how to stylize your components. What is the finality of an UIComponent? isn't it to render HTML content? Thus providing a default and general css could be a good answer to this problem and my multi-templating feature another one because each template will come with its own css files to make an application change its look and feel. But are these solutions enough in the perspective to have any single UIComponent available in the JSF ecosystem to be customizable with css? wow, how many style classes should we remember in this case? too much for my little head thus I'm only with you if you find conventions at first
          Hide
          kito75 added a comment -

          I think this should really be part of the core JSF spec, unless we're going to have a components spec anytime soon. We really need to standardize the work done by the component vendors so life is easier for developers who use more than one component suite (and component vendors don't have to reinvent the wheel).

          Show
          kito75 added a comment - I think this should really be part of the core JSF spec, unless we're going to have a components spec anytime soon. We really need to standardize the work done by the component vendors so life is easier for developers who use more than one component suite (and component vendors don't have to reinvent the wheel).
          Hide
          lamine_ba added a comment - - edited

          Multi-templating = Theming + Skinning

          Seam Themes (http://docs.jboss.org/seam/1.1CR1/reference/en/html/i18n.html)

          How a web designer can create different themes for a JSF application?
          How a web designer can create different skins for a JSF application?
          How can we share the themes?
          How can we share the skins?
          How can we package and unify the two concepts into one?

          Wouldn't be nice if you could download and use this kind of templates ( http://www.gelono.com/free-joomla-1.5-templates.html )

          Want to have a system like this one? (http://net.tutsplus.com/tutorials/other/creating-your-first-joomla-template/)

          Related issues:

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

          Show
          lamine_ba added a comment - - edited Multi-templating = Theming + Skinning Seam Themes ( http://docs.jboss.org/seam/1.1CR1/reference/en/html/i18n.html ) How a web designer can create different themes for a JSF application? How a web designer can create different skins for a JSF application? How can we share the themes? How can we share the skins? How can we package and unify the two concepts into one? Wouldn't be nice if you could download and use this kind of templates ( http://www.gelono.com/free-joomla-1.5-templates.html ) Want to have a system like this one? ( http://net.tutsplus.com/tutorials/other/creating-your-first-joomla-template/ ) Related issues: Multi-templating : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971
          Hide
          rdelaplante added a comment -

          Cross posting a comment from the JAVASERVERFACES_SPEC_PUBLIC-971 ticket because it is relevant:

          I have implemented a similar concept in JSF as well. In my experience you need a hierarchy of message resource bundles as well. You have a global system bundle for the majority of messages, and a template/brand/theme specific resource bundle that can override any of the global system messages, as well as add additional messages needed by the template/brand/theme (for their header, footer, etc.) You also need to take into account images that have text on them and need to be localized.

          Also, we have created a .xhtml facelet file for every screen of our application in each template/brand/theme directory. It's not just the header/footer that changes... the way they want to lay out panels looks different, their placement of buttons, etc. We need to make our application look exactly like the customer's existing website so their customers don't realize they have gone to another site for our particular workflow. Every customer is totally different.

          One more comment... every resource used by our template/brand/theme is listed in a configuration file so that when a web user requests it, we can make sure they are allowed to read that file and don't try to hack the system by doing things such as ../../../../. When I say resource, I'm talking about images, JavaScript files, CSS files, etc.

          Show
          rdelaplante added a comment - Cross posting a comment from the JAVASERVERFACES_SPEC_PUBLIC-971 ticket because it is relevant: I have implemented a similar concept in JSF as well. In my experience you need a hierarchy of message resource bundles as well. You have a global system bundle for the majority of messages, and a template/brand/theme specific resource bundle that can override any of the global system messages, as well as add additional messages needed by the template/brand/theme (for their header, footer, etc.) You also need to take into account images that have text on them and need to be localized. Also, we have created a .xhtml facelet file for every screen of our application in each template/brand/theme directory. It's not just the header/footer that changes... the way they want to lay out panels looks different, their placement of buttons, etc. We need to make our application look exactly like the customer's existing website so their customers don't realize they have gone to another site for our particular workflow. Every customer is totally different. One more comment... every resource used by our template/brand/theme is listed in a configuration file so that when a web user requests it, we can make sure they are allowed to read that file and don't try to hack the system by doing things such as ../../../../. When I say resource, I'm talking about images, JavaScript files, CSS files, etc.
          Hide
          Ed Burns added a comment -

          Resource Library Contracts is our current offering for what passes as skinning. If this feature needs to be re-addressed, another issue must be opened.

          Show
          Ed Burns added a comment - Resource Library Contracts is our current offering for what passes as skinning. If this feature needs to be re-addressed, another issue must be opened.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 2 weeks, 1 day
                2w 1d
                Remaining:
                Remaining Estimate - 2 weeks, 1 day
                2w 1d
                Logged:
                Time Spent - Not Specified
                Not Specified