Hi On 21 April 2010 06:44, Jason Pickering <jason.p.picker...@gmail.com> wrote: > Hi Viet, > > This is good news. > > So, my suggestion would be as follows. > > 1) Use the user settings to determine what the initial sorting should > be. Retrieve the first block of data based on whatever the user > settings are when the user enters the page. At this point there would > be no filter. > > 2) Should the user apply a filter, a new block of data would need to > be retrieved, based on the user input. One thing that I have noticed > is that there should be some sort of "delay" implemented until the > user finishes typing. It would be inefficient to send an AJAX request > each time the user types a character, but the request should be > generated once the user stops typing. This might require some > experimentation. My browser sort of does a "hiccup" each time I filter > on the data element list, as it filters after the input of each > character. If it would be possible to wait until the user actually > finishes typing, and then make the filter, this might result in a > better user experience. On a slow machine of mine, Firefox has crashed > several times while trying to filter the data element list. This is > one of the reasons I keep pushing so hard for this feature. :)
Haven't yet looked at the code but yes you do need to have some sort of software "hysteresis" on these Ajax kind of things to prevent excessive "chatter" and synchronisation problems. Part of the challenge is choosing the right amount of delay (and/or number of characters typed) to make the system behave reasonably in different network environments. In very high latency internet environments (like for example a lot of the Indian deployment) doing this auto dispatching of ajax requests would need to be tuned quite differently (or switched off) compared to running the app on the same workstation as the browser. I suspect the best short term solution is to be able to switch automatic filtering on and off. (Crazy aside: Ideally it would be *nice-to-have* a sort of adaptive timeout which recalibrates itself against the measured round-trip times of the ajax request/response. This is the same problem which TCP solves in the calculation of its timeouts. [To save myself recalculating - if I was writing a program in C on linux - I could use getsockopt(TCP_INFO) ] Nevertheless, implementing a similar algorithm in javascript working on the ajax RTTs is not beyond the bounds of reason. I guess I'd keep the time in a hidden div on the page with id='RTT'. Each time I sent a request I'd include a timestamp. On receiving the response I'd compare timestamp with current time and update the RTT. Of course RTTs can have considerable variance so I'd probably want to do what TCP does and keep a moving weighted average to avoid spikes causing me to set ridiculous timeouts.) > > 3) I would think it would be desirable to view all results (the > current view that we have) as well. > > 4) When I saw this with Murod in Tajikistan a few weeks back, I did > not pay attention to the details. But, it would be very nice to be > able to filter/search on other properties of the object. This is a > "nice to have" feature. Right now, we can only filter on the "name" > but there are situations when you need to filter the data element code > for instance. Not sure if this is possible. > > As Lars has detailed in a previous mail, a separate branch should > probably be made for this. Although I think it is a good and needed > feature, it may result in worse performance due to the roundtrips > between the client and the server that will be required each time a > new page needs to be generated. For large lists, i.e. patients and > data elements, it would seem to make sense in theory, but may actually > be worse than loading the entire DOM into the browser and filtering on > the client side. I think with lists like patients you really cannot get away from server side pagination. Cheers Bob > I would be of course available to test this with you. > > Lastly, thanks for taking a look at this. > > Regards, > Jason > > > > On Wed, Apr 21, 2010 at 7:22 AM, Viet Nguyen <phamquocv...@gmail.com> wrote: >> >> Hi Jason, >> >> I planed to move this to common ... but...somehow forgot it sorry :( >> Will do it asap. >> >> Something I would like to note here for sorting and filter functions. >> >> When we apply the paging, we need to sort from database, so there will be >> many changes in service methods. >> And for filter function, this is the most thing I have been worry about . >> Because we should not just filter in current page. I think we need to use >> ajax here. >> At this point, filter would be similar to search function, the only >> different thing is it effects on the fly. >> When user type something in filter text box, we get the result from >> database, then sort and paging that list, then return to the view. >> >> What do you think about this ? >> >> > > > > -- > -- > Jason P. Pickering > email: jason.p.picker...@gmail.com > tel:+260968395190 > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : dhis2-devs@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
