I agree with you, and in retrospect my solution won't fix all problems. However, it will fix one problem even if it won't fix all problems.
If the dataScroller isn't getting the correct number of rows back from the table, it might be a bug. I haven't looked at the guts of the dataScroller, but it should only need the number of rows in the dataTable and the dataModel to display properly. Neither of those values should be dependent upon rendering or ordering, except in the case where the dataTable doesn't exist yet. There's a known problem with default JSF 1.1 component tree creation where it renders each components before creating the next component during the initial component tree creation. For those cases, you should be able to solve the general JSF 1.1-based component creation problem by putting both objects in a child-rendering container component (like panelGroup) which will force both components to be created before they are rendered. Or you can use the facelets viewhandler which uses the "fixed" JSF 1.2 component tree creation behavior. Or you can upgrade to JSF 1.2 On 12/22/05, Miller, John <[EMAIL PROTECTED]> wrote: > I believe this problem would still be there if I were using a traditional > getter/setter approach. This exact problem with the rendering is used as an > example for the t:buffer myfaces example. My problems aside, just speaking of > that example > > I was simply stating that a page developer should never need to worry about > buffering a component to force the encode method of the dataTable to be > executed before the dataScroller gets executed. This could very simply be > accomplished within the two components themselves (rather than in the ui page) > > Page developers in my mind should know how to make beautiful UIs based on > components given to them, they shouldn't need to worry about things like > buffering a component. The fact that dataScroller has an attribute "for" > should be enough for the two components to work together regardless of how > they are laid out on the page. > > > -----Original Message----- > From: Mike Kienenberger [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 22, 2005 11:25 AM > To: MyFaces Discussion > Subject: Re: dataScroller implementation > > The problem isn't with how the components work. It's with your getter > returning different information each call. Instead of trying to fix > the component rendering behavior, you need to fix your data source. > > I'd recommend that you put your data source in a request-scoped bean, > and then cache the result. This will insure that every request the > data is fetched once and only once. > > public class requestScopedBean { > private List cachedData = null; > > public List getData() { > if (null == cachedData) { > // load cachedData > } > return cachedData; > } > } > > On 12/22/05, Miller, John <[EMAIL PROTECTED]> wrote: > > Ahhh Thank You, if I had only looked at the buffer example earlier I could > > have saved many hours. > > > > > > This worked, however I don't like how a page developer needs to worry about > > when the rendering is called . You should be able to just lay components > > out on a page and not have to worry about when the model is updated. As a > > suggested enhancement to dataScroller (and any other component that has a > > "for" attribute) the encode method should be able to do the buffering > > automatically (maybe callback to the component its for attribute > > references) that way you can lay these components out before the component > > they are "for" > > > > Could someone who is also on the dev group please forward this thread there > > as a suggestion. Thanks for the help. > > > > > > > > > > > > -----Original Message----- > > From: Mathias Brökelmann [mailto:[EMAIL PROTECTED] > > Sent: Thursday, December 22, 2005 5:06 AM > > To: MyFaces Discussion > > Subject: Re: dataScroller implementation > > > > take a look into the t:buffer component > > > > 2005/12/21, Miller, John <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > This is related to the "RE: Tobago SheetRenderer calls getter for list > > > twicely." Thread. > > > > > > > > > > > > It appears that where the dataScroller is on a page determines when in the > > > lifecycle it obtains information about the dataModel. > > > > > > I have a datable with a dataScroller on the top and bottom. There is a > > > button that toggles whether the Table shows "Closed Events" or not . It > > > appears that the dataScroller on top renders itself before the dataTable > > > is > > > updated, hence showing an incorrect number of pages. See the below code : > > > > > > > > > > > > <t:commandButton value="Hide Closed Events" > > > rendered="#{eventDataList.showClosed}" > > > > > > actionListener="#{eventDataList.togleShowClosed}" /> > > > > > > <t:commandButton value="Show Closed Events" rendered="#{! > > > eventDataList.showClosed}" > > > > > > actionListener="#{eventDataList.togleShowClosed}" /> > > > > > > > > > > > > > > > > > > <h:panelGrid> > > > > > > <t:dataScroller for="events"> > > > > > > ... > > > > > > </t:dataScroller> > > > > > > <t:dataTable id="events" value="#{eventDataList.data}" > > > > > > > ... > > > > > > </t:dataTable> > > > > > > > > > > > > <t:dataScroller for="events"> > > > > > > ... > > > > > > </t:dataScroller> > > > > > > <h:panelGrid> > > > > > > > > > > > > > > > > > > The getData method must go to the DB every time, hence is not a true > > > getter, > > > but unfortunately obtaining data from the DB every page request is a > > > requirement. > > > > > > > > > > > > > > > > > > > > > > > > NOTICE: This message, including all attachments transmitted with it, is > > > for > > > the use of the addressee only. It may contain proprietary, confidential > > > and/or legally privileged information belonging to Litle & Co. No > > > confidentiality or privilege is waived or lost by any mistransmission. If > > > you are not the intended recipient, you must not, directly or indirectly, > > > use, disclose, distribute, print or copy any part of this message. If you > > > believe you have received this message in error, please delete it and all > > > copies of it from your system and notify the sender immediately by reply > > > e-mail. Thank you. > > > > > > -- > > Mathias > > > > > > > > NOTICE: This message, including all attachments transmitted with it, is > > for the use of the addressee only. It may contain proprietary, confidential > > and/or legally privileged information belonging to Litle & Co. No > > confidentiality or privilege is waived or lost by any mistransmission. If > > you are not the intended recipient, you must not, directly or indirectly, > > use, disclose, distribute, print or copy any part of this message. If you > > believe you have received this message in error, please delete it and all > > copies of it from your system and notify the sender immediately by reply > > e-mail. Thank you. > > >
