About the layout component set

[sergeysmirnov]

Layout component set is a number one desired non-yet-implemented-feature according to the http://www.jboss.org/community/docs/DOC-11862

It is suggested to be implemented during the next development phase in the scope of RichFaces 3.3.1

There are several third-party examples of implementation, including:
1. the complex behavior with embedded splitters, headers, hidden and slided panels like:
EXT JS: http://extjs.com/deploy/dev/examples/layout/complex.html
Yahoo UI: http://developer.yahoo.com/yui/examples/layout/adv_layout_source.html

2. classical SWING approach and attempt to implement it for the web

3. scriptless approach with using CSS and semantic layout:
http://developer.yahoo.com/yui/grids/


We had already some proposal for feature spec:
http://anonsvn.jboss.org/repos/richfaces/management/design/Split%20Panel%20component/
It uses the first approach from the list above. The feature used to be proposed to be implemented in RichFaces 3.3.0, but was not approved

Alex Smirnov and I suggest to take the thing approach as a base for future development because it is lightweight (only css), support cross-browsers solution, generates semantical layout. The nested layout is also available:

http://developer.yahoo.com/yui/3/examples/cssgrids/cssgrids-nesting-grids_source.html

The advanced features such as splitters, hidden and slided panels might be added later based on the end developers' feedback.


WDYT?

[alexsmirnov]

A scriptless approach with CSS-only layout looks better solution. I've already use Yahoo grids for a page layouts. This is a page template :

<a:page
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:h="http://java.sun.com/jsf/html"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:s="http://jboss.com/products/seam/taglib"
 xmlns:a="http://richfaces.org/a4j"
 pageTitle="#{title}" format="xhtml">
 <a:loadStyle src="/css/grids.css" />
<div id="doc3" class="yui-t2">
 <div id="hd"> <ui:insert name="header"/>
</div>
 <div id="bd">
 <div id="yui-main">
 <div class="yui-b"><div class="yui-g">
 <!-- YOUR DATA GOES HERE -->
 <ui:insert name="content"/>
 </div>
 </div>
 </div>
 <div class="yui-b"><!-- YOUR NAVIGATION GOES HERE --></div>
 <ui:include src="/include/pagesList.xhtml"/>
 </div>
 <div id="ft">Footer is here.</div>
 </div>
</a:page>

This code could be converted into something like :

<a:page
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:h="http://java.sun.com/jsf/html"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:a="http://richfaces.org/a4j"
 pageTitle="#{title}" format="xhtml">
<f:facet name="header" >
<!-- header content -->
</f:facet>
<f:facet name="menu" >
<!-- navigation menu content -->
</f:facet>
<rich:gridLayout width='100%'>
<!-- content -->
<rich:gridLayout >
<f:facet name="footer" >
<!-- footer content -->
</f:facet>
</a:page>

Other horizontal, vertical or grid layout components could also based on the CSS.

[sergeysmirnov]

The wiki page has been added:
http://www.jboss.org/community/docs/DOC-13336

[meetoblivion]

A simple CSS/GridLayout isn't really what people are looking for/hoping for (at least my perspective). I know from my own management's perspective one of the "hot" things about a competitor *coughadfcough* is the very nice sliding panel layout. As you already pointed out, the proposed solution would be a way to just simply rewrite the templates. what i'm hoping for is ways to lock down certain UI components in a portal, and allow for others to be moved.

[joblini]

I am currently using a JQuery Splitter plugin http://methvin.com/splitter/ with a Richfaces/Seam application to provide an "explorer" like interface, with a richfaces Treeview on the left side (navigation panel) and a client area on the right side.

The above mentioned splitter works well, is being actively developed, and fits well with Richfaces as it is based on JQuery.

[sergeysmirnov]

The wiki page has been updated:
http://www.jboss.org/community/docs/DOC-13336

[sergeysmirnov]

New update with examples of using:

http://www.jboss.org/community/docs/DOC-13336

[meetoblivion]

"joblini" wrote:
I am currently using a JQuery Splitter plugin http://methvin.com/splitter/ with a Richfaces/Seam application to provide an "explorer" like interface, with a richfaces Treeview on the left side (navigation panel) and a client area on the right side.

The above mentioned splitter works well, is being actively developed, and fits well with Richfaces as it is based on JQuery.

the biggest thing i see wrong with that approach has to do with using the layout as a frameset replacement. from a performance standpoint i'd also prefer something that could be prerendered server side (apply all styles to it); not to mention it would likely be easier from a developer standpoint to disable applying the layout javascript via richfaces capabilities, not relying on the jquery integration to do it.

[joblini]

"meetoblivion" wrote:

"joblini" wrote:
I am currently using a JQuery Splitter plugin http://methvin.com/splitter/ with a Richfaces/Seam application to provide an "explorer" like interface, with a richfaces Treeview on the left side (navigation panel) and a client area on the right side.

The above mentioned splitter works well, is being actively developed, and fits well with Richfaces as it is based on JQuery.

the biggest thing i see wrong with that approach has to do with using the layout as a frameset replacement. from a performance standpoint i'd also prefer something that could be prerendered server side (apply all styles to it); not to mention it would likely be easier from a developer standpoint to disable applying the layout javascript via richfaces capabilities, not relying on the jquery integration to do it.

The advantage of this approach is that the layout can be dynamically resized on the client. This means the splitter can be moved and the window sizes are recalculated and redisplayed instantly.

I think that this is something that would enhance, not replace, the server side layout. In other words. server side layout as Serge describes on the wiki, but with further ability to resize using Jquery.

Oh, and I'll have a donut with that too, if its not too much trouble :-)

[sergeysmirnov]

The Requirement Specification prepared for the RichFaces 3.3.1 (beginning of May)

http://anonsvn.jboss.org/repos/richfaces/management/design/layout/FuncSpec-Layout.doc

[meetoblivion]

"joblini" wrote:
The advantage of this approach is that the layout can be dynamically resized on the client. This means the splitter can be moved and the window sizes are recalculated and redisplayed instantly.

I think that this is something that would enhance, not replace, the server side layout. In other words. server side layout as Serge describes on the wiki, but with further ability to resize using Jquery.

Oh, and I'll have a donut with that too, if its not too much trouble :-)

I agree with this 100%. My thought is that this feature really needs JS API support (via richfaces, prototype, or whatever) in order to really be complete, as the templating support in facelets really makes this feature seem like it's already there, and its up to the developers to figure out how they want to lay things out. for example, my main app uses a centered layout, so adding a header/footer/sidebar really doesn't help me much.

[jbalunas]

"meetoblivion" wrote:

I agree with this 100%. My thought is that this feature really needs JS API support (via richfaces, prototype, or whatever) in order to really be complete, as the templating support in facelets really makes this feature seem like it's already there, and its up to the developers to figure out how they want to lay things out. for example, my main app uses a centered layout, so adding a header/footer/sidebar really doesn't help me much.

I'd like to see more dynamic layout features in the future too, but this is the first iteration to get us there.

I think that "layout" features mean a lot of different things to different people ;-)

What are you thinking of:
- dynamic resizing of the layouts on the client?
- Drag-n-drop areas with state savings on the server (think google)?
- Something like the jira dashboard page (portal like)?
- More options than just header/footer/sidebar?
- other?

[jbalunas]

Some comments on the component spec:

How do people feel about changing "rich:layoutPanel " to "rich:layout". It has the same meeting and is more precise.

The skinning options will all be empty unless set by users right? So if the layout components are used with no settings it is clear?

It is not clear if the rich:layoutPanel is required to be nested inside of the rich:page. Hopefully it is not.

Could you update various grids and layout areas using "reRender". This would effectively adjust the layout using a4j? Although perhaps not perfect this could allow for some dynamic behavior out of the box.

[sergeysmirnov]

How do people feel about changing "rich:layoutPanel " to "rich:layout". It has the same meeting and is more precise.

layoutPanel is building block for creating layout. I.e., semantically, layoutPanel belongs to layout, but not a layout itself.

The other possible names are layoutBox (because of rectangle shape) or layoutBlock (as far as it is rendered to block html element in case of html renderKit)
We choice more abstract name - layoutPanel. Panel is a usual postfix for RichFaces components.

The skinning options will all be empty unless set by users right? So if the layout components are used with no settings it is clear?

This is an issue we are not on the same page yet. I strongly disagree to provide the default margins, padding and background color. However, some RichFaces components have pre-defined font size and font-family. So, ability to have a correspond rules on the top level is an option.

It is not clear if the rich:layoutPanel is required to be nested inside of the rich:page. Hopefully it is not.

Originally, Y! CSS Grid does not require it. I.e. the nested panel might be nested in any block element. So, rich:layoutPanel will not require to have a facet of the rich:page as a parent as well.

Could you update various grids and layout areas using "reRender". This would effectively adjust the layout using a4j? Although perhaps not perfect this could allow for some dynamic behavior out of the box.

Yes, if it does not break the layout itself.

[jbalunas]

"SergeySmirnov" wrote:

How do people feel about changing "rich:layoutPanel " to "rich:layout". It has the same meeting and is more precise.

layoutPanel is building block for creating layout. I.e., semantically, layoutPanel belongs to layout, but not a layout itself.

The other possible names are layoutBox (because of rectangle shape) or layoutBlock (as far as it is rendered to block html element in case of html renderKit)
We choice more abstract name - layoutPanel. Panel is a usual postfix for RichFaces components.

I think it should either be rich:layout or rich:layoutPanel the others I don't like.

The skinning options will all be empty unless set by users right? So if the layout components are used with no settings it is clear?

This is an issue we are not on the same page yet. I strongly disagree to provide the default margins, padding and background color. However, some RichFaces components have pre-defined font size and font-family. So, ability to have a correspond rules on the top level is an option.

I think that layout components should not impose any styling rules (except for the obvious layout spacing) unless the user specifically sets them. Setting them to reasonable values should be very easy though.