Message-ID: <1374394862.3786.1485855334239.JavaMail.confluence@ip-10-127-227-164> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3785_1622446204.1485855334239" ------=_Part_3785_1622446204.1485855334239 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
By default, the Search Service returns 25 results so, without pagination= , the current interface allows you to view only the 25 Locations. To add th= e pagination, we need to modify the whole component stack to accep= t an offset parameter and to use it:
offse=
t
parameteroffset
should be used in the view service when doing =
the AJAX requestoffset
parameterAs you can see in the corresponding commit, this is =
a purely Symfony-related task where we have to modify the routing.yml=
to accept an optional parameter and the action to use it.
This is detailed in the Symfony Controller= documentation.
offset
param=
eterThe PlatformUI application does not support route with optional paramete=
rs, so as a result we are forced to declare a new route which will accept t=
he new parameter. To do that, we have to modify the application plugin to a=
dd a second route called eZConfListOffset
:
// adding a new route so that we don't have anything els= e to change // and we can manage the default `offset` value in the view ser= vice app.route({ name: "eZConfListOffset", path: "/ezconf/list/:offset", view: "ezconfListView", service: Y.eZConf.ListViewService, sideViews: {'navigationHub': true, 'discoveryBar': false}, callbacks: ['open', 'checkUser', 'handleSideViews', 'handle= MainView'], });=20
The new route is very similar to the existing one with the exception of =
its path
property.
The route placeholder concept is documented in the YUI = Router component.
offset
parameterDepending on which route is matched, an offset parameter might be availa=
ble. The matched route parameters are available in the request object store=
d in the request
attribute of the view service. So to work wit=
h both the eZCon=
fList
route and the eZConfListOffset
route, the view service has to check if an =
offset was passed and to use 0 as its default value if none is provided. On=
ce that is done, it can build the URI to use to do the AJAX request. The
_load: function (callback) { // the request allows to retrieve the matched parameters var offset =3D this.get('request').params.offset, uri; if ( !offset ) { offset =3D 0; } uri =3D this.get('app').get('apiRoot') + 'list/' + offset; Y.io(uri, { method: 'GET', on: { success: function (tId, response) { this._parseResponse(response); callback(this); }, failure: this._handleLoadFailure, }, context: this, }); },=20
At this point, the interface in the browser should remain the same, but =
by using for instance the URL /ez#/ezconf/list/10
, you check t=
hat the offset is correctly taken into account.
To have working pagination links, the first thing to do is to change th=
e server side code to generate them. In the corresponding =
commit we also define the default limit at 10 elements.=
span> Like for the Location links, the server side code is not really able =
to generate a link in the JavaScript application, so we have to generate th=
e markup with the offset as metadata so that the view can recognize and cor=
rectly handle those links. So those links get a data-offset
at=
tribute with the corresponding offset:
{% block content %} <!-- [...] this list is generated, removed here to keep this code short = --> <ul class=3D"ezconf-list-pagination"> <li class=3D"ezconf-list-page ezconf-list-previous"> {% if previous is not same as(false) %} <a href=3D"{{ path('list', {offset: previous}) }}" class=3D"ezco= nf-list-page-link" data-offset=3D"{{ previous }}">« Previous&l= t;/a> {% else %} <span>« Previous</span> {% endif %} </li> <li class=3D"ezconf-list-page ezconf-list-next"> {% if next %} <a href=3D"{{ path('list', {offset: next}) }}" class=3D"ezconf-l= ist-page-link" data-offset=3D"{{ next }}">Next »</a> {% else %} <span>Next »</span> {% endif %} </li> </ul> {% endblock %}=20
After, we just have to change the view code to handle a tap on =
the next/previous links and when this happens, we can again fire the navigateTo
application level event to ask the view service to tr=
igger the navigation but this time to the eZConfListOffset
rou=
te with the given offset
, this is done with:
YUI.add('ezconf-listview', function (Y) { Y.namespace('eZConf'); Y.eZConf.ListView =3D Y.Base.create('ezconfListView', Y.eZ.ServerSideVi= ew, [], { events: { '.ezconf-list-location': { 'tap': '_navigateToLocation' }, '.ezconf-list-page-link': { 'tap': '_navigateToOffset' // new event detected }, }, _navigateToOffset: function (e) { var offset =3D e.target.getData('offset'); e.preventDefault(); this.fire('navigateTo', { routeName: 'eZConfListOffset', routeParams: { offset: offset, }, }); }, // ... the rest remains unchanged, removed to keep the code short }); });=20
After this change, the pagination should work as expected and you should= be able to navigate through the complete list of Locations.
The resulting code can be seen in the 7_pagination
tag on GitHub<=
/a>, this step result can also be viewed as a diff between tags 7_pagination
The next and final step is to add a way for the user to filter by Content Type.