Pagination patch

Hi all,

I created patch for pagination for Dataelement listing for truck head (1586) and send it via: bzr send -o pagination.patch. It did go and I don't know where did it actually go. Please check if it is there.

regards,
murod

Hi ,

I developed a brand new paging feature for patient list. Please see the screen shot

?ui=2&view=att&th=12741d645fd0ad56&attid=0.1&disp=attd&realattid=ii_12741d645fd0ad56&zw

Here I have many features for user :

  • On the right , you can see a paging traveling links, I hard coded to show maximum 5 pages, so if you are in page 4th and there are 8 pages, then list of pages is : 2,3,4,5,6
  • On left side, there are two function :
  • User can change the side of page, default size can be set it the action class, or in action config in struts.xml. After changing the page size, start page will be 1.
  • Jump to page is a very useful feature I think, when there are many pages and you just don’t want to click so many times on the traveling links.
    All input fields will be effected by onchange event.

To implement this, I created a PagingUtil class, here is the code on the action class

        pagingUtil = new PagingUtil( RequestUtil.getCurrentLink(ServletActionContext.getRequest()), pageSize == null ? defaultPageSize : pageSize );

       
        pagingUtil.setCurrentPage( currentPage == null ? 0 : currentPage );

       
        total = patientService.countGetPatientsByOrgUnit( organisationUnit );

       
        pagingUtil.setTotal( total );
       

        patients = patientService.getPatientsByOrgUnit( organisationUnit , pagingUtil.getStartPos(), pagingUtil.getPageSize() );

The constructor of the pagingUtil has two params:

  1. BaseLink : this should be the current link of the request, include all param, so if there is a searchText, I will add that searchText param to this baseLink. Later, I use this link to redirect user, just only change the pageSize and currentPage param.
  2. PageSize.
    the pagingUtil object will be sent to .vm file

On .vm file, implement this is easy :slight_smile:

   <div class="paging-container">

        <div class="paging-center">
            #parse( "/dhis-web-maintenance-patient/paging.vm" )

        </div>
    </div>

You just need to put this div to the end of the list.

I put everything in the paging.vm , so you just have to parse it . Actually I tried to use #macro… but don’t know why velocity can not identify the #macro when I put it in another file and use #parse function to include it …

So , the dependencies are : RequestUtil.class, PagingUtil.class , paging.vm , paging.css.

All the codes are commited , you can check it out in patient module. I have just implemented this for SearchPatientAction.class , and only for list all patient case. ( listAll = TRUE )

Regards,

···

On Tue, Mar 9, 2010 at 8:32 AM, Murodullo Latifov murodlatifov@yahoo.com wrote:

Hi all,

I created patch for pagination for Dataelement listing for truck head (1586) and send it via: bzr send -o pagination.patch. It did go and I don’t know where did it actually go. Please check if it is there.

regards,

murod


Viet Nguyen

Hi Viet, this looks quite elegant…

If the PagingUtil class is general, any chance we can move it to the dhis-support-system project so that it can be used by other modules if required later?

Lars

image

···

On Tue, Mar 9, 2010 at 9:20 AM, Viet Nguyen phamquocviet@gmail.com wrote:

On Tue, Mar 9, 2010 at 8:32 AM, Murodullo Latifov murodlatifov@yahoo.com wrote:

Hi all,

I created patch for pagination for Dataelement listing for truck head (1586) and send it via: bzr send -o pagination.patch. It did go and I don’t know where did it actually go. Please check if it is there.

regards,

murod

Hi ,

I developed a brand new paging feature for patient list. Please see the screen shot

?ui=2&view=att&th=12741d645fd0ad56&attid=0.1&disp=attd&realattid=ii_12741d645fd0ad56&zw

Here I have many features for user :

  • On the right , you can see a paging traveling links, I hard coded to show maximum 5 pages, so if you are in page 4th and there are 8 pages, then list of pages is : 2,3,4,5,6
  • On left side, there are two function :
  • User can change the side of page, default size can be set it the action class, or in action config in struts.xml. After changing the page size, start page will be 1.
  • Jump to page is a very useful feature I think, when there are many pages and you just don’t want to click so many times on the traveling links.
    All input fields will be effected by onchange event.

To implement this, I created a PagingUtil class, here is the code on the action class

        pagingUtil = new PagingUtil( RequestUtil.getCurrentLink(ServletActionContext.getRequest()), pageSize == null ? defaultPageSize : pageSize );



       
        pagingUtil.setCurrentPage( currentPage == null ? 0 : currentPage );



       
        total = patientService.countGetPatientsByOrgUnit( organisationUnit );



       
        pagingUtil.setTotal( total );
       



        patients = patientService.getPatientsByOrgUnit( organisationUnit , pagingUtil.getStartPos(), pagingUtil.getPageSize() );

The constructor of the pagingUtil has two params:

  1. BaseLink : this should be the current link of the request, include all param, so if there is a searchText, I will add that searchText param to this baseLink. Later, I use this link to redirect user, just only change the pageSize and currentPage param.
  2. PageSize.
    the pagingUtil object will be sent to .vm file

On .vm file, implement this is easy :slight_smile:

   <div class="paging-container">



        <div class="paging-center">
            #parse( "/dhis-web-maintenance-patient/paging.vm" )



        </div>
    </div>

You just need to put this div to the end of the list.

I put everything in the paging.vm , so you just have to parse it . Actually I tried to use #macro… but don’t know why velocity can not identify the #macro when I put it in another file and use #parse function to include it …

So , the dependencies are : RequestUtil.class, PagingUtil.class , paging.vm , paging.css.

All the codes are commited , you can check it out in patient module. I have just implemented this for SearchPatientAction.class , and only for list all patient case. ( listAll = TRUE )

Regards,

Hi Viet, this looks quite elegant…

If the PagingUtil class is general, any chance we can move it to the dhis-support-system project so that it can be used by other modules if required later?

Lars

Yeah, I can move the PageUtil class to dhis-support-system, paging.vm and paging.css to common-resource.

If I remember correctly…I think you also have a RequestUtil class somewhere…

Actually, to get current request path I just call the method request.getServletPath() , but I’m not sure it works for all modules… so I put it in a util class, then later I can modify that link ( maybe add or remove a “/” , or something like that… )

···


Viet Nguyen

Sorry, I forgot to mention the javascript methods.

function changePageSize( baseLink )
{

var pageSize = jQuery("#sizeOfPage").val();
window.location.href = baseLink +"pageSize=" + pageSize ;

}
function jumpToPage( baseLink )
{

var pageSize = jQuery("#sizeOfPage").val();
var currentPage = jQuery("#jumpToPage").val();

window.location.href = baseLink +"pageSize=" + pageSize +"&currentPage=" +currentPage;

}

So I guess, this will have to be moved to common-resources…
Should I create new file or put it in common.js ?

···

2010/3/9 Viet Nguyen phamquocviet@gmail.com

Hi Viet, this looks quite elegant…

If the PagingUtil class is general, any chance we can move it to the dhis-support-system project so that it can be used by other modules if required later?

Lars

Yeah, I can move the PageUtil class to dhis-support-system, paging.vm and paging.css to common-resource.

If I remember correctly…I think you also have a RequestUtil class somewhere…

Actually, to get current request path I just call the method request.getServletPath() , but I’m not sure it works for all modules… so I put it in a util class, then later I can modify that link ( maybe add or remove a “/” , or something like that… )


Viet Nguyen


Viet Nguyen

commons.js would be fine. Also moving the vm templates to commons-resources is good.

···

2010/3/9 Viet Nguyen phamquocviet@gmail.com

2010/3/9 Viet Nguyen phamquocviet@gmail.com

Hi Viet, this looks quite elegant…

If the PagingUtil class is general, any chance we can move it to the dhis-support-system project so that it can be used by other modules if required later?

Lars

Yeah, I can move the PageUtil class to dhis-support-system, paging.vm and paging.css to common-resource.

If I remember correctly…I think you also have a RequestUtil class somewhere…

Actually, to get current request path I just call the method request.getServletPath() , but I’m not sure it works for all modules… so I put it in a util class, then later I can modify that link ( maybe add or remove a “/” , or something like that… )


Viet Nguyen

Sorry, I forgot to mention the javascript methods.

function changePageSize( baseLink )
{

var pageSize = jQuery("#sizeOfPage").val();
window.location.href = baseLink +"pageSize=" + pageSize ;

}
function jumpToPage( baseLink )
{

var pageSize = jQuery("#sizeOfPage").val();
var currentPage = jQuery("#jumpToPage").val();



window.location.href = baseLink +"pageSize=" + pageSize +"&currentPage=" +currentPage;

}

So I guess, this will have to be moved to common-resources…
Should I create new file or put it in common.js ?

It would seem this was implemented for the patient system. Has there
been any effort to move it to a more common place, so it can be used
by other modules?

I am asking for two reasons.

1) Currently, ALL data elements are loaded when editing data elements.
In our case, this results in a lot data being sent across a very small
pipeline. Operations with data elements (sort for example) are very,
very sluggish. This might help to improve the situation.

2) Bob and I have had a very lengthy discussion about the data set
sections. It is quite a mess. I think Bob is working on a fix, but it
would be useful to have this functionality here. One may have many
data elements in a given section, and it would be useful to be able to
sort/filter them efficiently.

Regards,
Jason

···

2010/3/9 Lars Helge Øverland <larshelge@gmail.com>:

2010/3/9 Viet Nguyen <phamquocviet@gmail.com>

2010/3/9 Viet Nguyen <phamquocviet@gmail.com>

Hi Viet, this looks quite elegant..
If the PagingUtil class is general, any chance we can move it to the
dhis-support-system project so that it can be used by other modules if
required later?
Lars

Yeah, I can move the PageUtil class to dhis-support-system, paging.vm and
paging.css to common-resource.

If I remember correctly...I think you also have a RequestUtil class
somewhere....

Actually, to get current request path I just call the method
request.getServletPath() , but I'm not sure it works for all modules... so
I put it in a util class, then later I can modify that link ( maybe add or
remove a "/" , or something like that.... )

--
Viet Nguyen

Sorry, I forgot to mention the javascript methods.

function changePageSize( baseLink )
{
var pageSize = jQuery("#sizeOfPage").val();
window.location.href = baseLink +"pageSize=" + pageSize ;
}
function jumpToPage( baseLink )
{
var pageSize = jQuery("#sizeOfPage").val();
var currentPage = jQuery("#jumpToPage").val();
window.location.href = baseLink +"pageSize=" + pageSize
+"&currentPage=" +currentPage;
}

So I guess, this will have to be moved to common-resources...
Should I create new file or put it in common.js ?

commons.js would be fine. Also moving the vm templates to commons-resources
is good.
_______________________________________________
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

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

Jason,

Not sure that this will help you, but when setting up the datasets for Sierra Leone I always started by creating data element groups, and then when creating data sets and data set sections I added all data elements from a group. This made it easier for me as the data element group editor UI is working fine and also has the two dimensional view.

Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email: titlestado@who.int|Tel: +41 788216897

Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

···

2010/4/20 Jason Pickering jason.p.pickering@gmail.com

It would seem this was implemented for the patient system. Has there

been any effort to move it to a more common place, so it can be used

by other modules?

I am asking for two reasons.

  1. Currently, ALL data elements are loaded when editing data elements.

In our case, this results in a lot data being sent across a very small

pipeline. Operations with data elements (sort for example) are very,

very sluggish. This might help to improve the situation.

  1. Bob and I have had a very lengthy discussion about the data set

sections. It is quite a mess. I think Bob is working on a fix, but it

would be useful to have this functionality here. One may have many

data elements in a given section, and it would be useful to be able to

sort/filter them efficiently.

Regards,

Jason

2010/3/9 Lars Helge Øverland larshelge@gmail.com:

2010/3/9 Viet Nguyen phamquocviet@gmail.com

2010/3/9 Viet Nguyen phamquocviet@gmail.com

Hi Viet, this looks quite elegant…

If the PagingUtil class is general, any chance we can move it to the

dhis-support-system project so that it can be used by other modules if

required later?

Lars

Yeah, I can move the PageUtil class to dhis-support-system, paging.vm and

paging.css to common-resource.

If I remember correctly…I think you also have a RequestUtil class

somewhere…

Actually, to get current request path I just call the method

request.getServletPath() , but I’m not sure it works for all modules… so

I put it in a util class, then later I can modify that link ( maybe add or

remove a “/” , or something like that… )

Viet Nguyen

Sorry, I forgot to mention the javascript methods.

function changePageSize( baseLink )

{

var pageSize = jQuery("#sizeOfPage").val();
window.location.href = baseLink +"pageSize=" + pageSize ;

}

function jumpToPage( baseLink )

{

var pageSize = jQuery("#sizeOfPage").val();
var currentPage = jQuery("#jumpToPage").val();
window.location.href = baseLink +"pageSize=" + pageSize

+“&currentPage=” +currentPage;

}

So I guess, this will have to be moved to common-resources…

Should I create new file or put it in common.js ?

commons.js would be fine. Also moving the vm templates to commons-resources

is good.


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

Jason P. Pickering

email: jason.p.pickering@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

Hi Ola,

Thanks, but this is not applicable in my case. All of our data
elements have been imported from DHIS14. The data set ordering is
correct there, but not imported, and thus not respected in 2. The
fundamental problem is the that the datasetmembers object has no
sortorder. The sortorder persisted in dataelements is pretty close to
the order in DHIS1.4 (although not exact, which is a bit strange), but
even this is not respected when it comes to data set sections. Just
look at the code, and you will see what the problems are.

The issue that I am discussing (in this thread) is really about
sending what is necessary and practical to the client. It seems to be
totally inefficient (and certainly not scalable) to send several
hundred data elements across the wire at one time. Why not take a
block of 30 and allow people to page through them? Allowing
presentation by different sort orders (data set order, data element
order, alphabetical order, code order) are things that 1.4 has, and
there has been (at least in my assessment) a proven need for them in
the field. Again, all of this is are suggestions, which I hope can be
improved upon.

Regards,
JPP

···

On Tue, Apr 20, 2010 at 8:55 PM, Ola Hodne Titlestad <olatitle@gmail.com> wrote:

Jason,

Not sure that this will help you, but when setting up the datasets for
Sierra Leone I always started by creating data element groups, and then when
creating data sets and data set sections I added all data elements from a
group. This made it easier for me as the data element group editor UI is
working fine and also has the two dimensional view.

Ola Hodne Titlestad |Technical Officer|
Health Metrics Network (HMN) | World Health Organization
Avenue Appia 20 |1211 Geneva 27, Switzerland | Email:
titlestado@who.int|Tel: +41 788216897
Website: www.healthmetricsnetwork.org

Better Information. Better Decisions. Better Health.

2010/4/20 Jason Pickering <jason.p.pickering@gmail.com>

It would seem this was implemented for the patient system. Has there
been any effort to move it to a more common place, so it can be used
by other modules?

I am asking for two reasons.

1) Currently, ALL data elements are loaded when editing data elements.
In our case, this results in a lot data being sent across a very small
pipeline. Operations with data elements (sort for example) are very,
very sluggish. This might help to improve the situation.

2) Bob and I have had a very lengthy discussion about the data set
sections. It is quite a mess. I think Bob is working on a fix, but it
would be useful to have this functionality here. One may have many
data elements in a given section, and it would be useful to be able to
sort/filter them efficiently.

Regards,
Jason

2010/3/9 Lars Helge Øverland <larshelge@gmail.com>:
>
>
> 2010/3/9 Viet Nguyen <phamquocviet@gmail.com>
>>
>>
>> 2010/3/9 Viet Nguyen <phamquocviet@gmail.com>
>>>
>>>>
>>>> Hi Viet, this looks quite elegant..
>>>> If the PagingUtil class is general, any chance we can move it to the
>>>> dhis-support-system project so that it can be used by other modules
>>>> if
>>>> required later?
>>>> Lars
>>>>
>>>
>>> Yeah, I can move the PageUtil class to dhis-support-system, paging.vm
>>> and
>>> paging.css to common-resource.
>>>
>>> If I remember correctly...I think you also have a RequestUtil class
>>> somewhere....
>>>
>>> Actually, to get current request path I just call the method
>>> request.getServletPath() , but I'm not sure it works for all
>>> modules... so
>>> I put it in a util class, then later I can modify that link ( maybe
>>> add or
>>> remove a "/" , or something like that.... )
>>>
>>> --
>>> Viet Nguyen
>>>
>>
>> Sorry, I forgot to mention the javascript methods.
>>
>> function changePageSize( baseLink )
>> {
>> var pageSize = jQuery("#sizeOfPage").val();
>> window.location.href = baseLink +"pageSize=" + pageSize ;
>> }
>> function jumpToPage( baseLink )
>> {
>> var pageSize = jQuery("#sizeOfPage").val();
>> var currentPage = jQuery("#jumpToPage").val();
>> window.location.href = baseLink +"pageSize=" + pageSize
>> +"&currentPage=" +currentPage;
>> }
>>
>> So I guess, this will have to be moved to common-resources...
>> Should I create new file or put it in common.js ?
>>
>
> commons.js would be fine. Also moving the vm templates to
> commons-resources
> is good.
> _______________________________________________
> 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
>
>

--
--
Jason P. Pickering
email: jason.p.pickering@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

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

Hi Jason,

I planed to move this to common … but…somehow forgot it sorry :frowning:
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 ?

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. :slight_smile:

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 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@gmail.com> wrote:

Hi Jason,

I planed to move this to common ... but...somehow forgot it sorry :frowning:
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@gmail.com
tel:+260968395190

Hi

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. :slight_smile:

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

···

On 21 April 2010 06:44, Jason Pickering <jason.p.pickering@gmail.com> wrote:

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@gmail.com> wrote:

Hi Jason,

I planed to move this to common ... but...somehow forgot it sorry :frowning:
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@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

Hi,

agreed that pagination is needed on long lists like data elements and indicators. Jason, could you take the bother to write a blueprint? I guess you have almost done it with your last mail.

Re the filtering I think we are mixing this up a bit. Currently filtering happens on the client side. It can continue to do that even if we use pagination as the filter function simply moves elements back and forth from a hidden list.

Also, currently we have on-the-fly filtering. Would it be simpler if we just have a button which says “Filter” instead, ie letting the user decide when to perform the filtering? Easier and maybe better?

Agree that this is important and that we really need to improve usability/performance in “high latency internet environments”. Downloading the data element list with 1000 elements can be around 1 MB which is unacceptable. We have currently reduced the amount of html in the page + made the delete function “ajaxified” in order to avoid reloading the list, but more must be done.

Lars

Hi Lars,
I will write up the blueprint. It is becoming my specialty. :slight_smile:

Personally, I think the filter button is a good thing to test. The
on-the-fly filtering is really causing me a lot of headaches. On
Ubuntu, on a relatively slow machine, the browser greys out while
performing a filter, sometimes for a minute or so. This does not seem
like a particularly complicated operation, but it is very annoying,
and the user has no idea what is happening. The machine just freezes
for a few seconds when filtering on data elements.

I am experiencing a very high latency environment right now, so it may
be a while before I can get launchpad to work.

Regards,
Jason

···

2010/4/21 Lars Helge Øverland <larshelge@gmail.com>:

Hi,
agreed that pagination is needed on long lists like data elements and
indicators. Jason, could you take the bother to write a blueprint? I guess
you have almost done it with your last mail.
Re the filtering I think we are mixing this up a bit. Currently filtering
happens on the client side. It can continue to do that even if we use
pagination as the filter function simply moves elements back and forth from
a hidden list.
Also, currently we have on-the-fly filtering. Would it be simpler if we just
have a button which says "Filter" instead, ie letting the user decide when
to perform the filtering? Easier and maybe better?
Agree that this is important and that we really need to improve
usability/performance in "high latency internet environments". Downloading
the data element list with 1000 elements can be around 1 MB which is
unacceptable. We have currently reduced the amount of html in the page +
made the delete function "ajaxified" in order to avoid reloading the list,
but more must be done.
Lars

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

Hi Lars,

I will write up the blueprint. It is becoming my specialty. :slight_smile:

Personally, I think the filter button is a good thing to test. The

on-the-fly filtering is really causing me a lot of headaches. On

Ubuntu, on a relatively slow machine, the browser greys out while

performing a filter, sometimes for a minute or so. This does not seem

like a particularly complicated operation, but it is very annoying,

and the user has no idea what is happening. The machine just freezes

for a few seconds when filtering on data elements.

John L here also thinks this is a good idea as they have experienced similar issues. I think we should go for it.

I am experiencing a very high latency environment right now, so it may

be a while before I can get launchpad to work.

Thanks… If you email the text I can register it…

···

2010/4/21 Jason Pickering jason.p.pickering@gmail.com

Regards,

Jason

Not only in Ubuntu but in Windows as well. I met this a lot of times. I had to type the phrase somewhere else then copy and paste it in the filter text area to avoid hanging of my computer. It’s really good to have the button, or just filter after user click ENTER.

···

Thuy
HISP Vietnam
+84902079126

Hi Lars,
I will write up the blueprint. It is becoming my specialty. :slight_smile:

Personally, I think the filter button is a good thing to test. The
on-the-fly filtering is really causing me a lot of headaches. On
Ubuntu, on a relatively slow machine, the browser greys out while
performing a filter, sometimes for a minute or so. This does not seem
like a particularly complicated operation, but it is very annoying,
and the user has no idea what is happening. The machine just freezes
for a few seconds when filtering on data elements.

Should maybe not throw out the baby with the bathwater. What you
describe shouldn't really happen - that's meant to be the asynchronous
in Ajax - and could well be a problem with our implementation. So I'd
go for an optional button - perhaps driven by a general system-wide
setting "No-Ajax-Please" which could be used in other parts of the UI
as well.

I am experiencing a very high latency environment right now, so it may
be a while before I can get launchpad to work.

I had some problems with launchpad last night. I think sometimes it
just gets bewildered.

Cheers
Bob

···

2010/4/21 Jason Pickering <jason.p.pickering@gmail.com>:

Regards,
Jason

2010/4/21 Lars Helge Øverland <larshelge@gmail.com>:

Hi,
agreed that pagination is needed on long lists like data elements and
indicators. Jason, could you take the bother to write a blueprint? I guess
you have almost done it with your last mail.
Re the filtering I think we are mixing this up a bit. Currently filtering
happens on the client side. It can continue to do that even if we use
pagination as the filter function simply moves elements back and forth from
a hidden list.
Also, currently we have on-the-fly filtering. Would it be simpler if we just
have a button which says "Filter" instead, ie letting the user decide when
to perform the filtering? Easier and maybe better?
Agree that this is important and that we really need to improve
usability/performance in "high latency internet environments". Downloading
the data element list with 1000 elements can be around 1 MB which is
unacceptable. We have currently reduced the amount of html in the page +
made the delete function "ajaxified" in order to avoid reloading the list,
but more must be done.
Lars

--
--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

I have written up a blueprint here. It seems a bit wishy-washy when I
read it now. Comments?

https://blueprints.launchpad.net/dhis2/+spec/server-side-pagination

Hi Jason,

Just one point, on my initial post of server side pagination I said there is search option result of which in turn is paginated too (replacement for client side hiding/filtering), after better implementation and colorizing by Vietnamese guys, I don't know what happened to search option, which could solve most of issues with search/filtering, and maybe sorting.

regards,
murod

···

----- Original Message ----
From: Jason Pickering <jason.p.pickering@gmail.com>
To: Bob Jolliffe <bobjolliffe@gmail.com>; Lars Helge Øverland <larshelge@gmail.com>
Cc: DHIS 2 developers <dhis2-devs@lists.launchpad.net>
Sent: Thu, April 22, 2010 11:50:21 AM
Subject: Re: [Dhis2-devs] Pagination patch

I have written up a blueprint here. It seems a bit wishy-washy when I
read it now. Comments?

https://blueprints.launchpad.net/dhis2/+spec/server-side-pagination

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

Thanks!

After looking more closely I realized that we are not using ajax calls for the filtering of the “main” dataelement list (or any of the others). We are simply hiding the rows that don’t match the filter with javascript/dom.

Then its a bit weird that you are getting these problems… What does your environment look like when you experience this freeze?

···

On Thu, Apr 22, 2010 at 8:20 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

I have written up a blueprint here. It seems a bit wishy-washy when I

read it now. Comments?

https://blueprints.launchpad.net/dhis2/+spec/server-side-pagination