You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Torsten Krah <tk...@fachschaft.imn.htwk-leipzig.de> on 2007/05/28 18:44:26 UTC

DataScroller - Rendering/Pagination problem when rendered attribute is set to a conditional EL expression

I want to render the paginator only, if the actual datasize is greater
than the actual row size.


Setting 

rendered="#{@managed-bean-name.size gt @managed-bean-name.rows}"

does reflect that and works, but if i got a list size of 2 and changing
the rows to 1 - paginator shows 2 pages. 
But you can't change the page - you are bound to page 1.

Deleting the rendered EL expression - paginator works again, but is
there all the time.

Should be a bug, shouldn't it?

Torsten

Re: DataScroller - Rendering/Pagination problem when rendered attribute is set to a conditional EL expression

Posted by Torsten Krah <tk...@fachschaft.imn.htwk-leipzig.de>.
This rendered stuff has even more problems:

Using:

rendered="#{not empty @managed-bean-name.users}"

at my t:dataTable, does result in breaking all actions, the table might
emit (deleting rows, editing some).
Using facestrace and message tag, no errors - lifecycle does complete
all 6 phases - but nothing happens - my bean methods aren't invoked.
Navigation actions neither.
No exceptions - all looks good, but nothing is done.

If i remove the rendered attribute of the table - stuff works again.

Did i miss something about the rendered attribute?

Torsten

Am Montag, den 28.05.2007, 18:44 +0200 schrieb Torsten Krah:
> I want to render the paginator only, if the actual datasize is greater
> than the actual row size.
> 
> 
> Setting 
> 
> rendered="#{@managed-bean-name.size gt @managed-bean-name.rows}"
> 
> does reflect that and works, but if i got a list size of 2 and changing
> the rows to 1 - paginator shows 2 pages. 
> But you can't change the page - you are bound to page 1.
> 
> Deleting the rendered EL expression - paginator works again, but is
> there all the time.
> 
> Should be a bug, shouldn't it?
> 
> Torsten