Ok, I've been doing a little bit more research and I don't think it's
as simple as "it doesn't work that way". I was going through JSF In
Action looking for something else and ran across this example. You'll
have to forgive the crappy formatting. I copied this from the PDF.
However, if you'll notice, the bean is in request scope. There are
previous and next buttons that are rendered depedning on if there are
records before or after the current index. They use method binding to
actionListener methods in the backing bean. So according to the
statements from you this shouldn't work either. But I know it does.
<managed-bean>
<description>Pages through history list.</description>
<managed-bean-name>showHistoryBean</managed-bean-name>
<managed-bean-class>
org.jia.ptrack.web.ShowHistoryBean
</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>rowsPerPage</property-name>
<value>3</value>
</managed-property>
<managed-property>
<property-name>visit</property-name>
<value>#{sessionScope.visit}</value>
</managed-property>
<managed-property>
<property-name>projectCoordinator</property-name>
<value>#{applicationScope.projectCoordinator}</value>
</managed-property>
<managed-property>
<property-name>statusCoordinator</property-name>
<value>#{applicationScope.statusCoordinator}</value>
</managed-property>
<managed-property>
<property-name>userCoordinator</property-name>
<value>#{applicationScope.userCoordinator}</value>
</managed-property>
</managed-bean>
<h:dataTable cellpadding="5" styleClass="table-background"
value="#{showHistoryBean.currentProjectHistory}"
var="operation"
binding="#{showHistoryBean.historyDataTable}"
rows="#{showHistoryBean.rowsPerPage}">
<h:column>
<h:panelGrid columns="1" width="100%" border="1"
styleClass="table-even-row">
...
<h:outputText value="#{operation.timestamp}">
<f:convertDateTime dateStyle="full" timeStyle="short"/>
</h:outputText>
<h:outputText
value="#{operation.fromStatus} -> #{operation.toStatus}"/>
<h:outputText value="(#{operation.user.role})"/>
...
<h:outputText value="Comments:"/>
<h:outputText value="#{operation.comments}"
styleClass="project-data"/>
...
</h:panelGrid>
</h:column>
<f:facet name="footer">
<h:panelGroup>
<h:commandLink actionListener="#{showHistoryBean.previous}"
rendered="#{showHistoryBean.showPrevious}"
style="padding-right: 5px;">
<h:outputText value="Previous"/>
</h:commandLink>
<h:commandLink actionListener="#{showHistoryBean.next}"
rendered="#{showHistoryBean.showNext}">
<h:outputText value="Next"/>
</h:commandLink>
</h:panelGroup>
</f:facet>
</h:dataTable>
public class ShowHistoryBean extends BaseBean
{
private int rowsPerPage = 5;
private UIData historyDataTable;
public ShowHistoryBean()
{
}
public UIData getHistoryDataTable()
{
return historyDataTable;
}
public void setHistoryDataTable(UIData historyDataTable)
{
this.historyDataTable = historyDataTable;
}
public int getRowsPerPage()
{
return rowsPerPage;
}
public void setRowsPerPage(int rowsPerPage)
{
this.rowsPerPage = rowsPerPage;
}
public List getCurrentProjectHistory()
{
return getVisit().getCurrentProject().getHistory();
}
public boolean getShowNext()
{
return (historyDataTable.getFirst() +
rowsPerPage) <
getCurrentProjectHistory().size();
}
public boolean getShowPrevious()
{
return (historyDataTable.getFirst()—
rowsPerPage) >= 0;
}
public void next(ActionEvent actionEvent)
{
int newFirst =
historyDataTable.getFirst() + rowsPerPage;
if (newFirst <
getCurrentProjectHistory().size())
{
historyDataTable.setFirst(newFirst);
}
}
public void previous(ActionEvent actionEvent)
{
int newFirst =
historyDataTable.getFirst() - rowsPerPage;
if (newFirst >= 0)
{
historyDataTable.setFirst(newFirst);
}
}
}
On 8/12/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> You are welcome!
>
> regards,
>
> Martin
>
> On 8/12/05, Gregg D Bolinger <[EMAIL PROTECTED]> wrote:
> > BTW - I used saveState for the updateMode and it works good. I can't
> > think you all enough for digging through this for me.
> >
> > Gregg
> >
> > On 8/12/05, Gregg D Bolinger <[EMAIL PROTECTED]> wrote:
> > > Ok guys. Thanks for the help, although it wasn't what I was looking
> > > for. I really appriciate it. I'll look into using saveState to fix
> > > my issue. I really don't want this in session scope because when I
> > > come back to the page, it requires too much cleanup.
> > >
> > > Thanks again.
> > >
> > > Gregg
> > >
> > > On 8/12/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > > If you create the bean request scope, the value of rendered for your
> > > > update button is always false, from what code you've posted.
> > > >
> > > > So even though it was true long enough to draw the button on your html
> > > > response, it's now out of sync when you resubmit a request. Your
> > > > html treats it as if it were "rendered", but your server state shows
> > > > it as not-rendered. Actions submitted from non-rendered buttons are
> > > > ignored (I'm basing this on how everything about a non-rendered
> > > > component is ignored, not because I've actually researched and proven
> > > > the issue).
> > > >
> > > > -Mike
> > > >
> > > > On 8/12/05, Gregg D Bolinger <[EMAIL PROTECTED]> wrote:
> > > > > Technically, the problem isn't solved yet. Why won't this work in
> > > > > request scope? actionListeners don't get brand new beans in the true
> > > > > sense of a page being requested for the very first time. If I have an
> > > > > inputText with a name in it and an actionListener on a button, when I
> > > > > press that button, the text is still in the textfield when the page
> > > > > refreshes. The point is, when in request scope, the commandButton is
> > > > > not registering the binding on the method for the non-rendered
> > > > > component, even when it is set to render on refresh. That doesn't
> > > > > make sense?
> > > > >
> > > > > Can one of you try it in request scope and tell me what happens?
> > > > >
> > > > > Gregg
> > > > >
> > > > > On 8/12/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > > > > Yeah, obviously you knew what you were doing since you helped solve
> > > > > > the problem :)
> > > > > > Me and my big mouth :)
> > > > > >
> > > > > > -Mike
> > > > > >
> > > > > >
> > > > > > On 8/12/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > > > > > > I am conentrating very much on exactly this aspect ;)
> > > > > > >
> > > > > > > regards,
> > > > > > >
> > > > > > > Martin
> > > > > > >
> > > > > > > On 8/12/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > > > > > > > I wrote,
> > > > > > > > >> What happens if you dump the render statement?
> > > > > > > >
> > > > > > > > On 8/12/05, Gregg D Bolinger <[EMAIL PROTECTED]> wrote:
> > > > > > > > >Then the update method is called just fine.
> > > > > > > >
> > > > > > > > I'd say this it the point to concentrate on. Not sure why you
> > > > > > > > and
> > > > > > > > Martin are looking at other things.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > http://www.irian.at
> > > > > > > Your JSF powerhouse -
> > > > > > > JSF Trainings in English and German
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
>
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German
>
