8 Replies Latest reply on Mar 13, 2009 8:00 AM by Jay Balunas

    layoutPanel: Semantic of the layout

    Sergey Smirnov Master

      Current we have the following implementation of the layoutPanel set:


      <rich:layoutPanel type="gc">
      
       <rich:layoutPanel type="u first">
       left part of the body
       </rich:layoutPanel>
       <rich:layoutPanel type="u">
       right part of the body
       </rich:layoutPanel>
      
       </rich:layoutPanel>


      I.e. the structure and applied types reflect the structure and applied css classes of the original Y! CSS Grid

      The advantages are:
      1. No innovations or future enhancement that need to be added (as well as tested) over the original Y! code
      2. Ability to refer to the Y! UI doc for details

      The disadvantages are:
      1. needs to memorize the possible type names.
      2. tightly linked with Y! CSS Grid. I.e. less room for the further enhancements
      3. needs to hardcode the restriction that top level layoutPanel should have no other children as layoutPanel
      4. In the newest version of CSS Grid (still in beta), Yahoo changes the class names (i.e. the advantage #2 above will not be valid in the future)

      Due the fact that we have more disadvantages than advantages we are thinking about more abstract solutions.

      In any case, the rendered layout will be the same: outer block with set of inner block. So, the changes are only on the declarative level. I.e. how to represent the feature on the XHTML (JSP) page.

      The are two major solutions: one with facets, the other with component.

      Facets example:

      <rich:layout leftPanelWidth="30%" centralPanelWidth="30%" middlePanelWidth="30%">
       <f:facet name="left">
       .....
       </f:facet>
       <f:facet name="center">
       .....
       </f:facet>
       <f:facet name="right">
       .....
       </f:facet>
      
       </rich:layout>


      Advantages:
      1. traditional JSF approach
      2. less number of used components
      3. more control on the synchronization between layout panels
      Disadvantages:
      1. facet has no own attributes, so the specific attributes go to the top level
      2. onclick, onmouseover and other onxxxxx are not available for layout panels

      The facet-less approach:

      <rich:layout>
       <rich:layoutPanel id="lfoo" type="left" width="30%">
       ...
       </rich:layoutPanel>
       <rich:layoutPanel id="cbar" type="central" width="30%">
       ...
       </rich:layoutPanel>
       <rich:layoutPanel type="right" width="30%">
       ...
       </rich:layoutPanel>
      </rich:layout>
      


      Advantages:
      1. each layout panel has own set of attributes
      2. ability to re-render each panel individually by explicitly defined id
      Disadvantages:
      1. more components required (two vs. one)
      2. broken synchronization is possible (after re-rendering on of the panel with non-appropriate set of attributes like width)

      WDYT ?

        • 1. Re: layoutPanel: Semantic of the layout
          Jay Balunas Master

          I agree that we should not be strictly based on yahoo grid terminology - that locks us in, and can cause unwanted assumptions over the layout component moving forward.

          Of the two alternatives I believe the 2 component approach is best.

          Here's why:

          - Tooling will be much easier and with components like this I believe it is needed.

          - The two disadvantages of the facet approach are major problems. The first will make the layoutpanel very attribute heavy, and the second seems artificially limiting.

          - The possibility of the broken synchronization is bad, but limited especially if we can catch it and post of warning in the logs.

          Questions:
          - Will there be more types that right, center, left?

          If so (and I hope there will be) then we would need a facet for each. I don't like that.

          My $.02

          -Jay


          • 2. Re: layoutPanel: Semantic of the layout
            Sergey Smirnov Master

             

            "jbalunas@redhat.com" wrote:

            Questions:
            - Will there be more types that right, center, left?



            Originally, Y! CSS Grid
            * has only right, center, left
            * the size of them are defined only in %, but in absolute values (px,em, pt etc)

            So, if we would not to enhance the original Y! CSS (otherwize that required much more times and resources), we can keep such restriction.

            In the future version we can expend the set and remove the restriction introducing "top", "bottom".

            Alternatively, we can use the SWING terms, BWT: west, east, north, south.
            WDYT?

            • 3. Re: layoutPanel: Semantic of the layout
              Jay Balunas Master

               

              "SergeySmirnov" wrote:

              Originally, Y! CSS Grid
              * has only right, center, left
              * the size of them are defined only in %, but in absolute values (px,em, pt etc)

              So, if we would not to enhance the original Y! CSS (otherwize that required much more times and resources), we can keep such restriction.


              I don't want to do an additional enhancements to the !Y CSS for the first release of layout components.



              In the future version we can expend the set and remove the restriction introducing "top", "bottom".

              Alternatively, we can use the SWING terms, BWT: west, east, north, south.

              I think we should stick left,right,center for now and see what feedback we get.

              -Jay

              • 4. Re: layoutPanel: Semantic of the layout
                Alexander Smirnov Master

                Ok, I'm prefer to create layout/layoutPanel components because facet does not support any attributes, so the outer 'layout' component will be overloaded by attributes.
                The Y! CSS Grid has no 'vertical' grid because it is not necessary, 'block' style elements will be placed in a vertical stack by default.

                • 5. Re: layoutPanel: Semantic of the layout
                  Jay Balunas Master

                   

                  "alexsmirnov" wrote:
                  Ok, I'm prefer to create layout/layoutPanel components because facet does not support any attributes, so the outer 'layout' component will be overloaded by attributes.
                  The Y! CSS Grid has no 'vertical' grid because it is not necessary, 'block' style elements will be placed in a vertical stack by default.


                  OK good s it sounds like we are on the same page here. Two components for the layout.

                  • 6. Re: layoutPanel: Semantic of the layout
                    Alexander Smirnov Master

                    Finaly, layout components going to this semantic:

                     <layout:layout>
                     <layout:layoutPanel position="centre" width="50*">Center panel</layout:layoutPanel>
                     <layout:layoutPanel position="left" width="20*">Left</layout:layoutPanel>
                     <layout:layoutPanel position="right" width="30*">Right</layout:layoutPanel>
                     <layout:layoutPanel position="top">Top</layout:layoutPanel>
                     <layout:layoutPanel position="bottom">Bottom</layout:layoutPanel>
                     </layout:layout>
                    

                    For a horizontally aligned panels the "width" attribute means a part of outer panel what that component takes. This is a same semantic as HTML elements have - see http://www.w3.org/TR/html401/types.html#type-multi-length.
                    For the 'top' or 'bottom" positions, we can render width value to the html style attribute directly.
                    For YUI-based layout panel only relative sizes are supported, while real width calculated as nearest value from predefined layouts. In future, we are free to going to any other values ( absolute or relative ).
                    P.S. I've confused about 'centre' word spelling. In the most dictionaries, 'centre' provided for a British English, while American's spells 'center'. What is right for our component ?

                    • 7. Re: layoutPanel: Semantic of the layout
                      Achim Grimm Newbie

                      Hi there,

                      the component looks great that way. :-) I personally would use the "centre"-way of spelling it.

                      Many thanks for the good work.

                      • 8. Re: layoutPanel: Semantic of the layout
                        Jay Balunas Master

                        Overall I like this approach it makes sense easily :-)

                        Here are some point:

                        * Although the MultiLength is less known I think it works well in this context.

                        * What is the behavior if a user enters "50", or "50%", etc... in the width? Will the component default, ignore, or throw an error?

                        * In this example would top and bottom have a "height" attribute?

                        * As for "centre" or "center" I think we should be consistent and stick with "center".