9 Replies Latest reply on Aug 4, 2009 10:29 AM by Jay Balunas

    RichFaces 4.0: components layout

    Lex Dmitriev Newbie

      In previous iteration of RF development we had some problems with component layouts. I have several proposal on restrictions which it is necessary to use in redesigning components, what can help us to avoid of these problems.

      So, common restrictions:

      1) It is necessary to fix font size. Besides, it is necessary to delete this parameter from skin.properties
      2) It is necessary to forbid use of components hight value in percents
      3) It is necessary to forbid use of multiline in components titles (e.g. panel header) and in tabs
      4) It is necessary to remake a skin structure (the skin structure should contain areas with properties of concrete component).


      Other restrictions concern concrete components and them it is necessary to discuss within the limits of these a component.

        • 1. Re: RichFaces 4.0: components layout
          Ilya Shaikovsky Master

           


          4) It is necessary to remake a skin structure (the skin structure should contain areas with properties of concrete component).


          If work on this - the work should be done really carefully.. We should not come to Exadel VCP 2.0 skinning again and have hundreds of properties in skin. (we had 3 times more components now)

          • 2. Re: RichFaces 4.0: components layout
            Ilya Shaikovsky Master

             


            3) It is necessary to forbid use of multiline in components titles (e.g. panel header) and in tabs


            B.t.w. the possibility to have multiline tabs header is very popular among the community and requested many times :(


            • 3. Re: RichFaces 4.0: components layout
              Jay Balunas Master

               

              "admitriev" wrote:

              1) It is necessary to fix font size. Besides, it is necessary to delete this parameter from skin.properties


              Can you describe this in a little more detail? One concern here is causing problems with accessibility, and limiting style too tightly.


              2) It is necessary to forbid use of components hight value in percents

              How would we enforce this? What problem would this solve?

              3) It is necessary to forbid use of multiline in components titles (e.g. panel header) and in tabs

              I agree with Ilya here I think having multi-line headers/tabs is pretty important.

              4) It is necessary to remake a skin structure (the skin structure should contain areas with properties of concrete component).

              Also agree here with Ilya, skinning is tricky ( as you know well ), and I get concerned about the # of styles.

              This is a good start to the conversation, but I think what we need more details and reasoning behind these restrictions. Can you provide examples of the issues these restrictions will solve? This way we can all understand this better, and perhaps come up with other solutions.

              In the end we need a balance between accessibility, functionality, and complexity.

              • 4. Re: RichFaces 4.0: components layout
                Ilya Shaikovsky Master

                 

                "ilya_shaikovsky" wrote:

                3) It is necessary to forbid use of multiline in components titles (e.g. panel header) and in tabs


                B.t.w. the possibility to have multiline tabs header is very popular among the community and requested many times :(


                hmmm.. sorry seems I get you wrong there.. you didn't talked about tabs splited to a few lines here.. right? but about content inside every header?

                But anyway even if so.. such questions was also asked. So we need to fully understand reasons before make restrictions.

                • 5. Re: RichFaces 4.0: components layout
                  Lex Dmitriev Newbie

                  I've got a discussion with Nick and Ilya today. As a result I have 8 points:

                  1) It is necessary to delete IE6 from list of supported browsers. We'll have supported browsers: IE7 and higher, FF3x and higher, Safari 3.3 and higher, Opera 9.6 and higher.

                  2) It is necessary to reject support of quirks mode (doctype) because "IE5 mode renders content as if it were displayed by Internet Explorer 7's quirks mode, which is very similar to the way content was displayed in Internet Explorer 5" (MSDN) and we'll not support IE6 and lower.

                  3) About value of component hight (and width) - this question should be discussed separately for each component. Generally these parameters should be deleted from component attributes and can be used by means of styleclasses.

                  4) We need to reject use of selectors when developing the components, that the user could use just a css classes for component restyling.

                  5) It is necessary to shorten a length of prefixes of css classes names

                  6) About headers/tabs font size fixing: this is necessary to use a DIV for components layout because we need to have the equal hight in different elements WITHOUT using a hight parameter (e.g. tabs). Now in tabs a table as a layout, because next cells can have the same height without mathematic script (it is very simple way).

                  7) Text multyline - the same situation as in previous case

                  8) It is necessary to make a review of skins for commenting, make some corrs of color schema, add several parameters (4-5, e.g. tableHeaderBackground etc). Earlier I had told about review only, not about global changing :)


                  • 6. Re: RichFaces 4.0: components layout
                    Jay Balunas Master

                     

                    "admitriev" wrote:

                    1) It is necessary to delete IE6 from list of supported browsers. We'll have supported browsers: IE7 and higher, FF3x and higher, Safari 3.3 and higher, Opera 9.6 and higher.

                    We discussed this a bit at the f-2-f - IE6 maybe a tricky one - but I agree and would love to drop support for it.

                    2) It is necessary to reject support of quirks mode (doctype) because "IE5 mode renders content as if it were displayed by Internet Explorer 7's quirks mode, which is very similar to the way content was displayed in Internet Explorer 5" (MSDN) and we'll not support IE6 and lower.

                    I am fine with this one/

                    3) About value of component hight (and width) - this question should be discussed separately for each component. Generally these parameters should be deleted from component attributes and can be used by means of styleclasses.

                    Agree - these are style/layout issues not directly component based issues

                    4) We need to reject use of selectors when developing the components, that the user could use just a css classes for component restyling.

                    Could you explain this a bit more?

                    5) It is necessary to shorten a length of prefixes of css classes names

                    Agree and we want to do this anyway to save bandwidth.

                    6) About headers/tabs font size fixing: this is necessary to use a DIV for components layout because we need to have the equal hight in different elements WITHOUT using a hight parameter (e.g. tabs). Now in tabs a table as a layout, because next cells can have the same height without mathematic script (it is very simple way).

                    I see the issue better now, and it seems reasonable, but there must be others using semantic layouts with the problem. I would be curious how other people have handled this situation.

                    7) Text multyline - the same situation as in previous case

                    This one I'm not as clear on. With the tabs the need is for multiple tabs to have the same height even though in diff divs. Where does the height restriction come from for general multi-line text. Can you show an example.

                    8) It is necessary to make a review of skins for commenting, make some corrs of color schema, add several parameters (4-5, e.g. tableHeaderBackground etc). Earlier I had told about review only, not about global changing :)

                    I agree a review of skins will be needed.


                    As we discussed offline I think all of these points should be in a new wiki page where we can track and update.

                    Thanks

                    • 7. Re: RichFaces 4.0: components layout
                      Sergey Smirnov Master

                      About skins:

                      I am agreed with Ilya that VCP2.0 set of skin parameters was a nightmare. It is really not a way to go. At the same time, working with skinning for developed "Themes" we had realized that it was really hard to pick the existing skin parameters. The required colors were missing. Even we found the right color, the name of them was nonsense for the purpose we try to use .

                      Current skin parameters set was designed four years ago. RF 4.0 is a good time to drop the legacy.
                      I suggest, the approach for naming the skin parameters and the way how they are picked up for using to skin to components should redesigned.

                      Instead of having the predefined names, you can follow the approach that is natural for web designers. I.e. they take the 3-5 base colors and then calculate (actually, pick in photoshop) the secondary colors as a different percentage of hue, saturation and brightness.

                      A while ago we spoke with Alex Smirnov about the way how it might be defined with the EL functions. JSF 2.0 gives an opportunity to use EL expression directly inside in the css files.

                      • 8. Re: RichFaces 4.0: components layout
                        Lex Dmitriev Newbie

                        I've made example of problems with multiline text and different contents heights in semantic layout without a mathematics script for element hight calculation. In these cases we have 2 choices: first - we need to reject use to different heights in different contents, second - user need to set heights for each layout element (e.g. for tabs)

                        • 9. Re: RichFaces 4.0: components layout
                          Jay Balunas Master

                          I think waiting for the wiki page with the code examples and more details will be best for now. I'll comment more once that is started.