[ 
https://issues.apache.org/jira/browse/TOBAGO-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660253#action_12660253
 ] 

Michael Bauer commented on TOBAGO-733:
--------------------------------------

Hi Volker, 

thanks for checking this out! 

I've re-testet your snippet from above with the modified version of 
UIGridLayout and it seems that you're right: the change which fixes my problem 
with the dynamic layout and the UICells blows the way the optional 
'errorMarker' is embedded in your example. - Too much of a quick shot I'm 
afraid... 

I came across this while I was trying to create a layout with UICells. 

In your example the behavior is as expected (with the unchanged UIGridLayout): 
if the rendered flag #{bean.error} returns false, the space for the image is 
given to the <tc:in-component. However, with using UICells for the layout the 
behavior is different: you have to specify a different value for the attribute 
spanX if for example the menu/menubar should not be visible. (Changing the 
rendered-attribute of a component might be required if the application could 
either be used standalone or embedded in a portal, which provides it's own 
navigation/footer etc.) 

I've taken your example from above to explain what my problem is. If you extend 
it a little and add UICells to it, the 20px of the cell for the image are not 
given to the cell containing the <tc:in component because of the missing spanX 
or better the addition of an unrendered cell to the layout: 

<tc:panel> 

 <f:facet name="layout"> 
  <tc:gridLayout rows="fixed;*" columns="fixed;20px;1*"/> 
 </f:facet> 

 <%-- First row --%> 
 <tc:cell spanX="3"> 
  <tc:menuBar id="menuBar"> 
   <%-- some menu entries go here --%> 
  </tc:menuBar> 
 </tc:cell> 

 <%-- Second row --%> 
 <tc:cell> 
  <tc:label value="label"/> 
 </tc:cell> 
 <tc:cell rendered="#{bean.error}"> 
  <tc:image value="image/errorMarker.gif" rendered="#{bean.error}"/> 
 </tc:cell> 
 <tc:cell> 
  <tc:in value="#{bean.value}"/> 
 </tc:cell> 

 <%-- Third row --%> 
 <tc:cell spanX="3"> 
 </tc:cell> 

</tc:panel> 

With a cell in the layout that has a spanX>1 defined, an unrendered cell still 
leaves an empty slot in the layout. Is this the desired behavior? Taking only 
the second row, the space is devided the same way as in the original example 
without the cells. 

I would expect the UIGridLayout to behave something like this for several rows: 
1. fixed;20px;1* => defines max. three columns 
2. spanX="3" of the first cell should be interpreted as: span over UP TO 3 
cells 
3. calculate which cells belong to which row using all defined cells 
(disregarding the rendered attribute here) => leads to 3 cells in the second 
row 
4. apply the column definition on each row separately, which produces the same 
result as if there was only the second row 

With that, the cells in the first and third row would span over the two 
rendered cells in the second row. In the second row, the cell containing the 
<tc:in-component would receive the space of the unrendered cell containing the 
image. 

However, I'm not sure if this would be the desired behavior in every use case, 
but it would feel more right to me. 


> Support for more dynamic layouts by evaluation of the rendered attribute in 
> UICell an UIGridLayout
> --------------------------------------------------------------------------------------------------
>
>                 Key: TOBAGO-733
>                 URL: https://issues.apache.org/jira/browse/TOBAGO-733
>             Project: MyFaces Tobago
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.0.20, 1.0.21, 1.1.0
>         Environment: Windows XP Professional
> Apache Tomcat 6.0.18
> Java6 Update 10
> MyFaces 1.2.5
> Tomahawk 12-1.1.8
> Tobago 1.0.20
>            Reporter: Michael Bauer
>            Priority: Minor
>         Attachments: tobago-core-1.0.20.jar, UICell.java, UIGridLayout.java
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Some child components of the grid layout might change their rendered state 
> during user interaction, for example if the user decides to not display a 
> menu component or an information box etc. In that case the layout should 
> dynamically devide the given space using appropriate row-/colspans. To 
> achieve this, two changes would be necessary:
> 1. Using UICell in a grid layout with dynamic spans:
> Let a managed bean support the dynamic layout by calculating the actual cell 
> spans. Add value bindings to UICell's spanX- and spanY-attributes like this 
> for example:
>   public Integer getSpanX() {
>         ValueBinding spanBinding = getValueBinding( ATTR_SPAN_X );
>         if(spanBinding != null)
>         {
>                 Object obj = spanBinding.getValue( getFacesContext() );
>             if(obj != null && obj instanceof Integer)
>             {
>                 Integer integer = (Integer) obj;
>                 return integer;
>             }
>         }
>         return spanX;
>   }
> 2. Calculating layout in UIGridLayout depending on the rendered state of the 
> child components (UICells in this case)
> If the child would be a cell and the cell would have a (changing!) value 
> binding for the rendered attribute, the cell and it's contents would not be 
> rendered - which is OK; However, the place taken by the not rendered cell 
> will not be filled by the other components, hence leaving an empty space in 
> the layout...
> Checking if a child is rendered before evaluating the grid layout fixes this.
> The necessary changes would have to be made in method "private List<Row> 
> createRows() {" for example like this:
>         boolean childRendered = component.isRendered();
>         if(childRendered)
>         {
>               rows.get(r).addControl(component, spanX);
>               rows.get(r).fill(c + 1, c + spanX, component.isRendered());
>         }
> With that, a child component with the attribute rendered set to false will be 
> ignored in the layout.
> The second change would need for a dynamic span-evaluation of the other 
> components in the same row as suggested in the first change.
> Regards,
> Michael

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to