Yes, I have just one call getting through to my DB, the session scoped bean with Paul's blocking method worked. The drawback with this approach, we may start thinking on cleaning session off of the unused objects, otherwise our app may consume too much cache on the server.
vlad On 7/6/07, daniel ccss <[EMAIL PROTECTED]> wrote:
Now I see your long answer, i´m going to read it, Vladimir you still have two calls to the DB, but you was the one who give me the tip of put the backing_bean on sesion to avoid that. I only have one call now. On 7/6/07, vlad10 <[EMAIL PROTECTED]> wrote: > > > Paul, > I hope you did not miss my email from late yesterday with 6 items. > I just discovered something in addition to this discussion. I have a > page > with a dataTable but no scroller, and I've noticed, that my method for > accessing DB was called twice right on start. That means the bug with > dup > calls is hidden in dataTable rather than dataScroller. > > vlad > > > Paul Iov wrote: > > > > Hi Daniel, > > > > have you read my long post about how the data are handled in internal > > storage? Do you have the same approach and what do you mean exactly > with > > "delete"? If you just delete the record from DB (i.e. via JDBC/SQL), > you > > have to set also _invalidated flag in my class, to force the internal > > storage to be reloaded. (It's not especially efficient but it should > > work.) If you have implemented your own delete(_whatever_) method in > > this class, this method have to delete the ID from internal storage > and > > then ensure, that the page will be refetched next time (i.e. with some > > extra boolean flag; in my code I just store the last ID-list generated > > during fetching of page and if it becomes changed [something was > > deleted/sorted in internal storage], I force the page to be > refetched). > > This should be the better way, since after delete/edit of an item only > > the current page of data will be refetched - not the whole dataset AND > > > the current page. ...and first after this comes the issue with > > dropScroller :). Probably, you don't need then this method at all. > > > > > > daniel ccss schrieb: > >> Hi Paul, I put your code in my backing_bean and call the method > >> dropScroller(String dataTableId) after the delete method was called, > I > >> send to this method the id of the data table: > >> > >> <t:dataTable id="data" styleClass="scrollerTable" ... > > >> > >> > >> But the dataTable doesn´t update, in my console I recived the > message: > >> " dropScroller called" but nothing happen. What else do I should do, > >> or what I'm doing bad. > >> > >> Also: > >> I guess Daniel, you are using event listener in your backing bean to > >> edit data directly in PagedList? It's the only way to have actual > copy > >> displayed without to reload this page. > >> > >> Yes, Paul in fact I´m doing that, and, as Vladimir, I call the DB > each > >> time the PageData change. When I didn´t have your improved class > >> PagedList, it works fine, since the fetch was doing many times for > >> each action and the data update in the DataTable. For that I was > >> thinking in some way put another condition on your filter for the > >> fetch where after I called the add/delete/edit method put that > >> variable in true and enter to the if to do the fetch, because I see > >> that when I click in the page number (a fetch is doing) the data > >> update in the DataTable. I hope your solution works for me It looks > >> pretty nice. > >> > >> On 7/5/07, *Vladimir Isakovich* <[EMAIL PROTECTED] > >> <mailto: [EMAIL PROTECTED] >> wrote: > >> > >> Paul, > >> many thanks for your answers. > >> > >> 1. Interestigly enough, after the warning the border is still > >> applied. If I try to do the same with style=..., there is no > effect. > >> this has nothing to do with the data fetching. > >> 2. I have a guess about two calls to fetchPage() in the > DataModel. > >> May be it's because we have 2 UIComponents called DataScroller > >> (one with buttons and another with the message). Shuld it be > >> posted as a bug on dataScroller? I've seen the defects page on > >> myFaces, but not familiar with the procedure of addin to that > list. > >> 3. I've got it why you have your pageSize being analized and used > >> in getDataModel(), your page explains it. I'll try to implement > >> the same with an additional inputText. > >> 4. I also noticed on your page - the dataScroller has just 2 > >> buttons plus numbers in between. This way your strategy of > >> fetching data chunks should work. I am using the "standard" > >> scroller which has in addition fast forward/backward and > >> first/last buttons, and in this case I think I'm better of > calling > >> DB every time (I've no way of predicting what page will be > >> requested next). > >> 5. Probably next thing I'll try to implement: edit/delete/add, > and > >> after that I'm planning to implement Ajax datascroller. It's not > a > >> good user experiense, when the whole page gets re-rendered on > >> every action. > >> 6. Although I've experience with javaScript, at least when I > >> compare myself with the java developers I've worked with, but > I've > >> never tried using XmlHttpRequest. I have this book: 'Pro JSF and > >> Ajax', but it was a diappointment after loading and gettin > running > >> their example to find out that it's based on some proprietary > >> jars. Since you're using this ajax dataScroller, could you please > > >> enlight me on any existing standard for ajax (are there some > >> 'standard' jars I can use as a base of my app)? > >> > >> thanks, vlad > >> > >> > >> On 7/5/07, *Paul Iov* < [EMAIL PROTECTED] > >> <mailto: [EMAIL PROTECTED]>> wrote: > >> > >> Well... just a bit refining > >> Vladimir Isakovich schrieb: > >>> > >>> Jul 5, 2007 1:12:09 PM > com.sun.facelets.tag.jsf.ComponentRule > >>> warnAttr > >>> WARNING: /web/sec/examples/largeTableScroller.xhtml @104,85 > >>> border="1" Property 'border' is not on type: > >>> org.apache.myfaces.component.html.ext .*HtmlGraphicImage* > >>> > >>> 2. I also can see a warning... > >>> > >> It's correct. The old good border="0" for image is deprecated > >> with HTML4. We should use CSS instead. > >> > >> > >> > >> > > > > > > > > -- > View this message in context: http://www.nabble.com/Tomahawk%2BDataScroller%2BWorkingWithLargeTables-tf4016097.html#a11470790 > > Sent from the MyFaces - Users mailing list archive at Nabble.com<http://nabble.com/> > . > >
