-
1. Re: About the layout component set
alexsmirnov Dec 23, 2008 8:06 PM (in response to sergeysmirnov)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. -
2. Re: About the layout component set
sergeysmirnov Feb 12, 2009 7:38 PM (in response to sergeysmirnov)The wiki page has been added:
http://www.jboss.org/community/docs/DOC-13336 -
3. Re: About the layout component set
meetoblivion Feb 15, 2009 12:47 PM (in response to sergeysmirnov)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.
-
4. Re: About the layout component set
joblini Feb 15, 2009 8:48 PM (in response to sergeysmirnov)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. -
5. Re: About the layout component set
sergeysmirnov Feb 18, 2009 7:16 PM (in response to sergeysmirnov)The wiki page has been updated:
http://www.jboss.org/community/docs/DOC-13336 -
6. Re: About the layout component set
sergeysmirnov Feb 20, 2009 6:45 PM (in response to sergeysmirnov)New update with examples of using:
http://www.jboss.org/community/docs/DOC-13336 -
7. Re: About the layout component set
meetoblivion Feb 20, 2009 8:08 PM (in response to sergeysmirnov)"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. -
8. Re: About the layout component set
joblini Feb 22, 2009 8:20 PM (in response to sergeysmirnov)"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 :-) -
9. Re: About the layout component set
sergeysmirnov Feb 25, 2009 6:28 PM (in response to 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 -
10. Re: About the layout component set
meetoblivion Feb 28, 2009 12:32 PM (in response to sergeysmirnov)"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. -
11. Re: About the layout component set
jbalunas Mar 1, 2009 9:41 AM (in response to sergeysmirnov)"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? -
12. Re: About the layout component set
jbalunas Mar 2, 2009 2:56 PM (in response to sergeysmirnov)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. -
13. Re: About the layout component set
sergeysmirnov Mar 2, 2009 4:53 PM (in response to sergeysmirnov)"jbalunas@redhat.com" 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."jbalunas@redhat.com" wrote:
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."jbalunas@redhat.com" wrote:
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."jbalunas@redhat.com" wrote:
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. -
14. Re: About the layout component set
jbalunas Mar 2, 2009 7:37 PM (in response to sergeysmirnov)"SergeySmirnov" wrote:
"jbalunas@redhat.com" 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."jbalunas@redhat.com" wrote:
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.