Right, JSF1.2 should fix this, if the row-count is known. What is when getRowCount() returns -1? Don't know much about data-scroller, either ;)
regards, Martin On 12/22/05, Miller, John <[EMAIL PROTECTED]> wrote: > I will add the request, and also may take a shot at the change over the next > few weeks > > -----Original Message----- > From: Martin Marinschek [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 22, 2005 12:30 PM > To: MyFaces Discussion > Subject: Re: dataScroller implementation > > In an ideal world, this would work, right... we could certainly add > something like an automatic buffer if it is necessary. I doubt that > we'll go into the trouble of doing it, though, if you don't want to do > it yourself and provide a patch ;) > > Please add a jira-ticket with a request for enhancement! > > Now, even more interesting about this thread is that both Simon and > Mike didn't find the solution to your problem! > > That must have occurred exactly _once_ since they both are on the > mailing list... > Now, what's up guys? Any excuse? ;) > > regards, > > Martin > > 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. > > > > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
