Allow a suffix for paginator object

[ghost]

It would be very helpful to allow a suffix for the Paginator object which then adds the suffix to the 'page='-Parameter, e.g. with suffix $this->suffix = '_34' it will be 'page' . $this->suffix . '='. The same has to be added for the handling of the parameter so ->get('page') will be ->get('page' . $this->suffix).

This change would allow more than one paginator per page if the module which uses the pageinator automatically uses the suffix parameter.

--- Originally created by hschottm on November 12th, 2008, at 08:08am (ID 255)

[leofeyer]

I know what you mean, although it does not sound very user friendly. Are you developing a particular module that could use this functionality? URLs would look like

http://domain.tld/home.html?page_34=2&page_12=3&page_2=1

That does not seem very logic - at least to me :-)

--- Originally created on November 12th, 2008, at 10:16am

[ghost]

Ok, I get you point regarding the URL. This is quite a mess :-) But with the introduction of the memberlist module it is possible to have multiple memberlists on a page. My former employer has a page with a list of Professors, a list of scientific staff, a list of technical staff, a list of secretaries and so on. In this case you have always the search field on top (which then filters ALL of the memberlists, even if you just like to filter one of them) and the paginator (if the lists are restricted to a given number of datasets) of one list works for all of them. This isn't very user friendly too. But it's a real life scenario.

The point is: I introduced my own module MemberExtensions where I slightly modified your memberlist module to allow the search field to work only for the list where it is attached. The same thing I wanted to do with the paginator but this isn't possible without having the possibility of a suffix.

Taking the example above I would not allow restricted lists so no paginator would be visible. But even if there are two modules on a page using the paginator object, you are running into some kind of inconsistency because a click to a paginator affects the other paginator as well. In these rare cases a suffix - if attached to the paginator object - would be of help.

Again: I can live without it but with the possibility to have multiple objects using the paginator on one page, there will be side effects.

--- Originally created by hschottm on November 12th, 2008, at 10:30am

[leofeyer]

I'll see what I can do.

--- Originally created on November 12th, 2008, at 10:35am

[fbender]

What about using the module ID as suffix automatically? Thus you will be able add a pagination to both the top and the bottom of a list without having extra code.

http://domain.tld/home.html?pager43=2&pager1=3

The framework will then be able to handle the whole pagination stuff internally ...

--- Originally created on November 12th, 2008, at 11:16pm

[leofeyer]

Helmut, I am a little unsure what I am supposed to do now :-) Do you still want me to add the suffix to the pagination class? It should not be a big deal.

--- Originally created on December 5th, 2008, at 01:26pm

[fbender]

I beg you to add it ;). I think helmut still wants this, too.

--- Originally created on December 5th, 2008, at 03:21pm

[ghost]

Sorry, I was "out in the field". I would prefer any solution which supports multiple paginators on a page. I think that I'm not the only one who would like to use multiple paginators. I don't insist that it has to be my proposal. If you have something better in mind - no problem. Maybe this should be discussed with some others. We don't have to force a decision right now...

--- Originally created by hschottm on December 5th, 2008, at 04:05pm

[leofeyer]

Well, all I am offering is to extend the Pagination class to support a suffix so you can use it in your custom module. I will not modify any core modules, because I think that pagination is something that relates to a page and should always be unique.

--- Originally created on December 5th, 2008, at 08:46pm

[leofeyer]

Until we have made up our minds, I am going to remove the milestone.

--- Originally created on December 12th, 2008, at 10:49am

[ghost]

Hi Leo, I clearly see the problem of creating some horrible URL constructs and somehow I don't want to do this. What about a session based solution? Only add one additional URL parameter which is the name/id of the table and store the previous sort options of other tables than the one mentioned in the URL parameter in the Session and retrieve it from there as well. A problem might be that you can't set an initial value for other tables than the one of the URL parameter.

For the special case that one has more than one paginator object on one page, there is the advantage that the pagination settings of the other tables do not change if the paginator is clicked in a certain table and I think the same would be possible for the tablesort parameters.

What do you think?

--- Originally created by hschottm on January 14th, 2009, at 05:26pm

[leofeyer]

I do not like this idea too much, because session storing does not work if you type in the URL directly or e.g. follow a link from an e-mail. The forum extension currently generates the breadcrumb trail this way and we are having a lot of problems to get it to work.

By the way, why don't we write in German?

--- Originally created on January 14th, 2009, at 06:22pm

[ghost]

Hi Leo, ok. Das kann ich nachvollziehen. So richtig gut finde ich das ja ehrlich gesagt auch nicht. Es war mir nur so in den Kopf gekommen und ich wollte es wenigstens mal angesprochen haben. Klar können wir gerne deutsch schreiben, ich komme nur grad von einem anderen Open Source Projekt an dem ich beteiligt bin und da ist Englisch die Sprache der Wahl... Ohne FloB jetzt irgendwie in den Rücken zu fallen, aber ja länger ich darüber nachdenke, umso weniger gefallen mir die Lösungen, die 3 zusätzliche URL-Parameter pro Tabelle generieren (column,sortorder,paginator). Google findet leider auch keine befriedigenden Ergebnisse für mehrere Paginator auf einer Seite. Wenn es Lösungen gibt, dann sind die im Prinzip alle Ajax/JavaScript basiert.

--- Originally created by hschottm on January 14th, 2009, at 06:38pm

[leofeyer]

Wenn es Lösungen gibt, dann sind die im Prinzip alle Ajax/JavaScript basiert.

Ja, genau zu diesem Schluss bin ich auch gekommen. Eine barrierefreie Lösung gibt zumindest solange nicht, bis die Screenreader endlich mit JavaScript klarkommen.

Bei Horst Eugen werde ich diese Sachen auf jeden Fall mittels Ajax umsetzen (z.B. das Wechseln der Monate im Mini-Kalender), weil ich nicht mehr einsehe, dass sich Millionen von Webdesignern der Politik von 5 oder 6 großen Firmen unterwerfen, die sich schlicht weigern, ihre Screenreader weiter zu entwickeln. Es wird dann einfach einen Hinweis geben "Achtung, dieses Feature ist nicht 100% barrierefrei".

Bei TYPOlight sehe ich da aber leider keine Möglichkeit, da wir die Barrierefreiheit von Anfang an als eines der Hauptkriterien beworben haben.

--- Originally created on January 14th, 2009, at 07:07pm

[leofeyer]

--- Originally closed on January 14th, 2009, at 07:07pm