dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

On 21 April 2010 06:44, Jason Pickering <jason.p.pickering@xxxxxxxxx> 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 <phamquocviet@xxxxxxxxx> 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.pickering@xxxxxxxxx
> tel:+260968395190
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>