8 Replies Latest reply: Apr 13, 2012 6:04 PM by Adrien Adrien RSS

RF 4: sandbox page layout component(s) feedback

Karsten Wutzke Expert

Hello all,


Bernard Labno and I have been discussing the RF 4 sandbox page layout component/s for some time now (Bernard has started the implementation). A few points were coming up which we'd like to discuss here.


The RF 4 page layout is mostly a copy-and-paste of the RF 3 implementation, with a few additions so far. Here's what it renders right now (SANDBOX):

<body id="j_idt4">
  <div class="rf-pg " id="j_idt4">
    <div class="rf-pg-hdr " id="j_idt4:hd">
      <div class="rf-pg-hdr-cnt" id="j_idt4:hdc"><span class="project-title">What Ever</span>
    <div class="rf-pg-cnt " id="j_idt4:cnt">
      <div class="rf-pg-m">
        <div class="rf-pg-bd ">
          <div style="">


Some issues with the old and now new codebase have piled up:


1. The rich:page component generates two redundant, inline CSS styles (style tag) under the html element (not shown):

.rf-pg{margin:auto 10px;width:auto;}


The default for CSS width already is auto, see http://www.w3schools.com/cssref/pr_dim_width.asp, so this would be equivalent to

.rf-pg{margin:auto 10px;}


I'm not sure what the above CSS is supposed to do.


If the first was supposed to center the content, the order should have been margin: 10px auto; as the above automatically creates an (ugly) 10px margin to the left and right between the body tag and the rf-pg div. Yuck. Not good when you put some "incompatible" CSS onto the body tag, e.g. a border or drop shadow. The second selector is for the nested, innermost content div, not sure why there's a float: left here. Opinions?


My one: I think we should remove this inline CSS entirely. I cannot


2. Why are there three nested divs rf-pg-cnt, rf-pg-m, and rf-pg-bd? I think they are unnecessary. See below for a new proposal.


3. There's a top border on rf-pg-m. Purpose? It should be deleted IMO, if not the div entirely.


4. The rich:page component generates the HTML body tag as well as a nested div tag with the CSS class rf-pg. Bernard has implemented styleClass and style attributes for the new rich:page component. We generally have to define whether the styleClass and style attributes are meant for the body tag or the rf-pg div. I think they should generally go to the topmost div rf-pg. There should however be the possibility to add custom classes to the body tag as well, e.g. "shadow". This can only be accomplished via a second pair of attributes called bodyStyleClass and bodyStyle. Please discuss.


Here's my take on a final proposal of the page layout component(s):

<body class="rf-pg-bdy">
  <div class="rf-pg">
    <div class="rf-pg-hdr"> <!-- f:facet name="header" -->
      <div class="rf-pg-hdr-cnt">Project Title</div>
    <div class="rf-pg-mnb" style="?"> <!-- f:facet name="menubar" -->
    <div class="rf-pg-lyt"> <!-- rich:layout example 3-column layout -->
      <div class="rf-pg-t" style="?"> <!-- layout:layoutPanel position="top" -->
      <div class="rf-pg-l" style="generated float: left; ..."> <!-- layout:layoutPanel position="left" -->
      <div class="rf-pg-c" style="no float at all?"> <!-- layout:layoutPanel position="center" -->
      <div class="rf-pg-r" style="generated float: right; ..."> <!-- layout:layoutPanel position="right" -->
      <div class="rf-pg-b" style="?"> <!-- layout:layoutPanel position="bottom" -->
    <div class="rf-pg-ftr"> <!-- f:facet name="footer" -->
      <div class="rf-pg-ftr-cnt">Contact etc.</div>


Discussion material is below.


5. Outer body RF class:

I know that rf-pg-bdy on the outer body tag is kind of inconsistent with the RF 4 naming that should be used. But rf-pg-bdy would best hint that this class is for the page body. In any case, if it doesn't work out, returning to the "old way" can be achieved by deleting the rf-pg-bdy class.


6. Menu bar:

As an enhancement I'd like to see some kind of menu bar, here rf-pg-mnb between the page header and the layout div. Many apps can use this as their place for a menu, some tabs, or simply some navigational breadcrumb space without having to use the top layoutPanel. Please discuss a name for such a facet: menubar (my vote), menu, menuBar, topbar, bar, ...


7. Layout container:

Maybe there should be a div around the left, center, and right divs, but I really don't see that. Maybe that was rf-pg-m (rich-page-main) someday? It's not necessary to me (discuss).


8. Floats:

The left component generates float: left, the right generates float: right. I tried a one-column layout panel with center, but it seems to generate a float: left. If I want to center that content, I haven't figured out how to do that. I think it can't be done with the generated inline float: left. IMO the center component shouldn't generate a float at all.


9. Naming:

Maybe the layout divs should be rf-pg-lyt-t, rf-pg-lyt-l, rf-pg-lyt-c, rf-pg-lyt-r, rf-pg-lyt-b? +1 for that!


Please discuss. I'm sure I didn't think about every aspect here (although I might be close ).



  • 1. Re: RF 4: sandbox page layout component(s) feedback
    Bernard Labno Master

    What's the advantage of layout component over facelet templating?

  • 2. Re: RF 4: sandbox page layout component(s) feedback
    Karsten Wutzke Expert

    The RichFaces look in general and the all-inclusive gradients resulting in a good look for almost no HTML/CSS and Facelets fiddling.


    Plus, if you consider extending the component, one could have the possibilities of collapsing certain layout elements or close (x) out some of them. Please have a look at the PrimeFaces layout component as to where the RF page layout should be going IMO: http://www.primefaces.org/showcase/ui/layoutHome.jsf


    I had hoped to discuss the technical details here instead of the high concepts or as to why this component is necessary.



  • 3. Re: RF 4: sandbox page layout component(s) feedback
    Brian Leathem Master

    @Karsten: first to address your specific questions:


    1. +1 let's remove the inline css

    2. the three nested divs would most likely have been for creating a container with rounded corners.  We should take a modern approach with the component, and target round-corner support using the CSS3 border-radius property; +1 for remvong the nested divs

    3. hard to say without seeing a screenshot, but the default style should probably be as non-invasive as possible; +1 for removing the border

    4. I would assign classes to the body tag with the facelet template myself, but I see no harm in providing body* styling attributes

    5. I think the outermost div should have the shortest name "rf-pg".  For the second outermost div, use something like "pg-in" for pg "inner"
    6. +1 for menubar - no reason to leave this out

    7. I'd have to fiddle with it to see the effect

    8. getting floats to line up cross-browser can be tricky, we may faces such external contraints here


    @Bernard: If you've done some work prototyping this, would you mind sharing it to the sandbox so others interested in the component can pick up where you left off?



    Next, I'd like to take a step back, and discuss what we are trying to achieve.  I agree in principle that the need for this component is dramatically reduced with the standardisation of Facelets in JSF 2 (I can see a page layout component being much more useful in the JSP days).  With facelets in JSF 2, you can achieve exactly what you've described by creating a facelet template, where the f:facets you define above map to ui:insert.  The piece that is missing is the built in skin support to style the layout.  This exact topic is being addressed in a parallel discussion.


    At a recent team meeting, we discussed the topic of templating in general. Goonzalad has proposed a jira supoprting such templates: RF-12017.  By prepackaging facelet templates as themes, with associated skinning files, I think we would be able to achieve a superset of the goals of the layout component.


    That being said, if someone wants to pursue creating such a rich:layout comopnent, there is no harm in that.  We should however make the effort to ensure that the layout classes and default skins co-ordinate.

  • 4. Re: RF 4: sandbox page layout component(s) feedback
    Karsten Wutzke Expert

    While I see your points about a new-style, more general page layout component, I suggest to implement it in an old fashion first. People that used it in RF 3 and want to port to RF 4 (like myself) would appreciate a component that isn't much different.


    Please consider adding an alternative page layout component if someone is willing to do the job. Though I doubt someone will anytime soon, so it's probably best to stick to something that already exists (also with the amount of time to put into such a component).


    +1 for sticking to the old one for backward compatibility reasons. (To be honest, it's still not good advertising to have RF 3 components available that haven't been ported to RF 4 yet... and we're already in the 4.2 if not 4.3 cycle...)



  • 5. Re: RF 4: sandbox page layout component(s) feedback
    Sergey Morenets Novice

    Karsten, totally agree.


    I am ready to port my application to RF4, however missing components still keep me waiting ...

  • 6. Re: RF 4: sandbox page layout component(s) feedback
    Adrien Adrien Apprentice

    waiting ....me too

  • 7. Re: RF 4: sandbox page layout component(s) feedback
    Bernard Labno Master





    <dependency> <groupId>org.richfaces.sandbox.ui.layout</groupId> <artifactId>layout-ui</artifactId> <version>4.1.0-SNAPSHOT</version> </dependency>
  • 8. Re: RF 4: sandbox page layout component(s) feedback
    Adrien Adrien Apprentice

    Thannnnnnnnksss!! :-)

    I'm going to try it!