custom database paging listbox

From Documentation
Revision as of 07:20, 19 November 2015 by Chillworld (talk | contribs)
DocumentationSmall Talks2015Decembercustom database paging listbox
custom database paging listbox

Author
Cossaer Filip
Date
December 01, 2015
Version
ZK 6.5 and above

Under Construction-100x100.png This paragraph is under construction.


Foreword

This small talk is how you could create your own custom component for real database pagination with a listbox and what's simple to use.
As I'm writing this small talk I will write about the problems and choices I encountered and explaining why I did it this way.
As all code, it's a working progress and I'm open to suggestions/refactoring's/improvements.

You can leave a comment below or create a discussion on ZK forum.


Introduction: Database paging listbox

While ZK has a lot of good components easy to use, I missed out some important one for me, and that's an easy to use database paging listbox.
You can do automatically paging but then your whole list is actually in your model.
If you wanted to do database paging you needed to set a <paging> and bind it to your viewmodel.
The viewmodel needed then methods for activePage, totalSize, pageSize and when I work with Spring this is already contained in mine Page I get from the repository.
I did some attempts on creating this with custom implementations of ListModel and the use of the autopaging of the listbox.
I failed here because the listbox inner paging doesn't make a difference between totalSize and pageSize.
If I used pageSize, I wasn't able to page to other pages.
If I used totalSize, everything worked BUT underlying the listbox generated totalsize minus pagesize empty objects.
For small queries it isn't so bad, but I had queries what have results of over 1000000 results while page was size 20.
The query was fast enough, but still the listbox takes a long time to load because it was creating the empty objects.
It's here where I decided to go for a custom listbox, where I add mine own paging above and handle it by myself.

Requirements

Now it was time to think about the requirements of the listbox.
What should it do and how to make it easy for usage.
The first thing what popped in mine head is MVVM. We all like it and let's be honest, it's ZK strongest point.
Then I was looking at the listbox and paging component.
The following attributes where important for me that I could set in the zul :

  • pageSize
  • model
  • selectedItem
  • selectedItems
  • pagingPosition
  • checkmark
  • multiple
  • detailed

Then it's up to how do I want to code it in the zul.
The first idea was to use it like this :

<paginglistbox>
      <auxhead>
        <auxheader/>
      </auxhead>
      <listhead>
        <listheader  />
        <listheader  />
      </listhead>
      <template name="model">
        <listitem>
          <listcell>
            <label value="${each.id}" />
          </listcell>
         </listitem>
      </template>
  </paginglistbox>

But then we have the problem because paginglistbox isn't a listbox but it's mine own component who has a listbox inside.
In a zul page, the paginglistbox should look like this :

  <paging/>
  <listbox/>
  <paging/>

Luckily there are templates in ZK. With the templates I could retrieve it and inject it in the listbox.
The usage of the paginglistbox would be changing to this :

<paginglistbox>
    <template>
      <auxhead>
       ...
      </template>
    </template>
  </paginglistbox>

Now we have 2 possible solutions what we could do :

  • Define a constant name to the template like you use <template name="model"> for your model.
  • Don't define a name but add the name of the template in the attribute of paginglistbox.

As I'm pretty lazy, I don't want to add the name of the template in the attributes.
But let's think ahead, if I add the name in attribute I can even use @load for that.
This means I can change the template name in runtime, witch means that if I create multiple templates I can easily switch between them.
This behavior does attract me more then mine laziness of not writing an extra attribute.

Creating the PagingListbox class

Here I am writing mine PagingListbox and everything is going great.
At that point I realize I'm forgetting 1 big thing namely sorting.
If we use sort="auto(property)" in the listheader we don't get database sorting but we sort only the page.
After some investigation of the Listheader class, I saw that if we use sort="client(property)" the sorting is enabled on the columns.
The next problem was getting that value back from the listheader. There is a setter but no suitable getter for it.
At this point I'm left with one very dangerous solution called reflection.
I don't like to use reflection because if ZK decide to change the variable name the effect would be in best case that sorting don't work anymore, in worst case we are getting errors.
The solution provides that with sort="client(id;name)" the pagerequest will receive the sortField as id;name

PagingListbox.java :

@ComponentAnnotation({"selectedItems:@ZKBIND(ACCESS=both,SAVE_EVENT=onSelect)",
    "selectedItem:@ZKBIND(ACCESS=both,SAVE_EVENT=onSelect)"})
public class PagingListbox extends Idspace implements AfterCompose {
        // implementation found on github link below.
   }

One of the things you will notice is the extending of IdSpace.
This is done so you could use in the paginglistbox scope some id's and if you set a second one, the id's are in a different idspace so they wouldn't clash.


The PagingModel

What's the role of the model.
Well, it should actually contains the page request to the database, but a request contains active page, pagesize, sortfield(s) and sortdirection
I'm again to a crossroad :

  • Do I make an abstract class where you could just need to implement 1 method, the query to the database.
  • Do I make a model, what's need an implementation of an interface for implementing the query to the database.

At first I'm tending to go for the first solution but then I was attending Venkat Subramaniam talk of Core Design Principles for Software Developers.
So I'm like yes you are right but it's so easy to make and use the abstract class.
But like a good student, I'm thinking of the advantages of the other way.
And I notice, if I work with the interface, I can create 2 implementations of the interface and switch them easy in the model without making a new instance of the model.
Reasons of doing this is maybe multiple databases, query with different filters when you use multiple templates,...

The interface is actually real simple, we only need 2 methods. The first on is getting the data and the second one is getting the totalsize, similar to this small talk.

PagingModelRequest.java

public interface PagingModelRequest<T> {
    Collection<T> getContent(int activePage, int pageSize, String sortField, SortDirection sortDirection);
    long getTotalSize();
}

And the code of the model

PagingModel.java

public class PagingModel<T> {

    private String sortField;
    private PagingModelRequest pagingModelRequest;
    private SortDirection sortDirection;

    public PagingModel(PagingModelRequest request) {
        this(request, null, null);
    }

    public PagingModel(PagingModelRequest request, String sortField) {
        this(request, sortField, null);
    }

    public PagingModel(PagingModelRequest request, String sortField, SortDirection sortDirection) {
        Objects.requireNonNull(request, "PageModelRequest can't be null.");
        this.pagingModelRequest = request;
        this.sortField = sortField;
        this.sortDirection = sortDirection == null ? SortDirection.ASCENDING : sortDirection;
    }

    public Collection<T> getContent(int activePage, int pageSize) {
        return pagingModelRequest.getContent(activePage, pageSize, sortField, sortDirection);
    }

    public long getTotalSize() {
        return pagingModelRequest.getTotalSize();
    }
    
    //getters and setters

    public void setPagingModelRequest(PagingModelRequest request) {
        Objects.requireNonNull(request, "PageModelRequest can't be null.");
        this.pagingModelRequest = request;
    }
}

You notice that you can't instantiate the model without a real instance of PagingModelRequest or use the setter with null object. There was also the problem with sortDirection. Because I wanted to create a component what could be used by any implementation on the backend, I needed to create a sortDirection with no reference to other frameworks, but still easy to change to your needs.

I came up with the following enum, you can change the enum yourself by adding more properties to it.
It's already configured for usage with Spring Data.

SortDirection.java

public enum SortDirection {

    ASCENDING("ASC","ASCENDING"),
    DESCENDING("DESC","DESCENDING");
    
    private final String shortName;
    private final String longName;

    private SortDirection(String shortName, String longName) {
        this.shortName = shortName;
        this.longName = longName;
    }
    
   // getters 
}

Declare your component

Under the folder WEB-INF there is the lang-addon.xml file.
Now it's time to add our component to this file.

<language-addon>
     <component>
        <component-name>paginglistbox</component-name>
        <extends>idspace</extends>
        <component-class>my.choosen.path.PagingListbox</component-class>
    </component>
</language-addon>

This makes that we can use our component in the zul like this without declaring any other stuff:

  <paginglistbox/>

Spring data paging

Because a lot of people use spring paging, I have created an abstract class for Spring usage : SpringPagingModelRequest.java
You can find the implementation in the github repository below this small talk.

Advantages of this class :

  • Implementation of sorting multiple fields, separated by ';', ',' or space.
  • Implementation of ignore case if wanted.
  • Implementation of fix direction of opposite direction sorting.

Example :

    <listheader sort="client(id;lower(name);asc(birthdate))/>

Explication :

  • First sort field is 'id'.
  • Second sort field is 'name' with ignoring case.
  • Thirth sort field is 'birthdate' but always sorted ascending.

Usage

I have explained everything about coming to this component but still the most important thing is how to use it.
There are some attributes required and some are optional.

  • template : required
  • model : required
  • pageSize : optional, default 20.
  • selectedItem : optional
  • selectedItems : optional
  • pagingPosition : optional, default "top" and possible values : "top","bottom","both". Any other value will shown no paging element.
  • checkmark : optional default false
  • multiple : optional default false
  • detailed : optional default true
  • emptyMessage : optional default empty string.


I'm going to show an example of the zul usage with multiple templates, one for edit and one for readOnly.

<paginglistbox model="@load(vm.pageModel)" pagingPosition="bottom" template="@load(vm.templateName)">
    <template name="readOnly">
      <listhead>
        <listheader label="id" sort="client(id)" />
        <listheader label="name" vflex="min" />
      </listhead>
      <template name="model">
        <listitem value="${each}" item="@ref(self.value)">
          <listcell>
            <label value="${each.id}" />
          </listcell>
          <listcell>
            <label value="@load(item.name)" />
          </listcell>
        </listitem>
      </template>
    </template>
    <template name="edit">
      <listhead>
        <listheader label="id" sort="client(id)" />
        <listheader label="name" vflex="min" />
      </listhead>
      <template name="model">
        <listitem value="${each}" xxx="@ref(self.value)">
          <listcell>
            <label value="@load(xxx.id)" />
          </listcell>
          <listcell>
            <textbox value="@bind(xxx.name)" />
          </listcell>
        </listitem>
      </template>
    </template>
    </template>
  </paginglistbox>

The viewmodel does need those methods :

public PagingModel getPageModel() {
        return new PagingModel(new PagingModelRequest(){
            private long totalSize;

            @Override
            public Collection getContent(int activePage, int pageSize, String sortField, SortDirection sortDirection) {
                Sort.Direction direction = Sort.Direction.fromString(sortDirection.getShortName());
                Page page = mySpringDataRepo.findAll(new PageRequest(activePage, pageSize, direction, sortField));
                totalSize = page.getTotalElements();
                return page.getContent();
            }

            @Override
            public long getTotalSize() {
                return totalSize;
            }
        }, "id");
    }
    
    public String getTemplateName() {
        return readOnly?"readOnly":"edit";
    }
}

Important note

 <template name="model">
        <listitem value="${each}" item="@ref(self.value)">

As you can see under the model template I fill the listitem's value with each, and I need to set a reference.
The binding doesn't work directly to the each object cause it's in a different lifecycle and by some strange behavior the each object is already gone before we can do the binding.
So a (hopefully temporarily) workaround is adding a reference : xxx="@ref(self.value)".
Like this we can do the binding to the xxx. You choose self the name for xxx.

Github link

Github repository