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
