Yeah, it's really kinda strange that JSF didn't ship with a "component
tree" scope. All the components fall into this scope automatically,
so it's a bit silly that the backing beans can't be configured the
same way. On the other hand, t:saveState is incredibly flexible, and
we might not have seen that component developed if there had been a
component scope.
On 8/12/05, Gregg D Bolinger <[EMAIL PROTECTED]> wrote:
> Ahhhh, ok. I see now. Thanks.
>
> Gregg
>
> On 8/12/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > The difference is that showNext doesn't depend on values in the
> > request-scoped bean.
> > It depends on values in the component tree (which is the same as
> > adding a value to the component tree using t:saveState).
> >
> > On 8/12/05, Gregg D Bolinger <[EMAIL PROTECTED]> wrote:
> > > 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
> > > >
> > >
> >
>
