Home » HTML » Pager » Bug #6987

[2006-03-02 00:35 UTC] remi at metacore dot net

Description:
------------
I've been trying to get Pager to play nice with QuickForm (i.e. QuickForm being used to generate a list of search results, and Pager being used to paginate them) on a page that requires GET parameters to display properly.

i.e. to search for the items, you go to the page /index.php?flag1=a&flag2=b . Once at that page a QuickForm is displayed (it is method POST and needs to stay as method POST) that you enter your search terms into and then click "Search".

When displaying the results, I need to use method POST with Pager (so that the QuickForm search-parameters get re-submitted to the page), but I also need to maintain the form target as /index.php?flag1=a&flag2=b -- from what I can tell, there is no current way to do this.

What I'd like is a configuration option that you can use to assign either GET parameters or the target URL if your Pager method is POST (so that you can have Pager configured to POST to the location $_SERVER['REQUEST_URI'], for example).

Right now I've got a wrapper object that does this for me in a very simple/kludgy way:

class my_Pager_Jumping extends Pager_Jumping
{
function _setOptions($options)
{
$r = parent::_setOptions($options);
if ($options['url'])
{
$this->_url = $options['url'];
}
return $r;
}
}

[2006-03-02 17:08 UTC] remi at metacore dot net

If I pass in the FormID option, then it uses that form but rewrites the 'action' tag to point at /index.php -- I need it to point to /index.php?flag1=a&flag2=b .

To start the form element is like this:

<form action="/index.php?flag1=a&flag2=b" method="post" name="search" id="search">

.. but the JavaScript created by Pager does this:

var form = document.getElementById("search");
var input = "";
form.action = "/as/index.php";
form.method = "POST";

... maybe if you are using a pre-existing form element with the Pager, you should leave it alone/not re-write things like .action and .method?

[2006-03-02 17:10 UTC] remi at metacore dot net

Oops, sorry. I made a typo.

... rather than:

var form = document.getElementById("search");
var input = "";
form.action = "/as/index.php";
form.method = "POST";

... it should be:

var form = document.getElementById("search");
var input = "";
form.action = "/index.php";
form.method = "POST";

[2006-03-03 08:29 UTC] remi at metacore dot net

No, what bothers me is that it loses the GET parameters on the form's 'action'. The example that I gave is about as full as I can make it, I think.

<form action="index.php?a=b&c=d" method="POST" id="form1">

... but if I set FormID to 'form1' in Pager, it will annihilate the ?a=b&c=d part with the javascript:

var form = document.getElementById("form1");
var input = "";
form.action = "/index.php";
form.method = "POST";

... I don't understand why the Pager re-writes the form action and method like it does -- if it has been told specifically to use it (i.e. if the user has set the FormID parameter), then isn't it reasonable to assume that the user has configured the form the way they want it to be, and Pager should leave it alone?

[2006-03-06 19:11 UTC] remi at metacore dot net

"you can pass them to Pager with the "extraVars" array option. This way you won't lose them. That holds true for any extra GET/POST parameter you want to propagate through the various pages."

The problem with 'extraVars' is that it *converts* the variables from GET to POST (in the example given). So instead of POSTing data *to* /index.php?flag1=a&flag2=b , it posts data to /index.php and passes flag1=a and flab2=b as POST data which breaks the page(s) that I speak of. AFAIK, 'extraVars' does not provide a way to label some variables as GET and some as POST. That would work, though, if it did provide it...

"Does it makes sense?"

It makes sense, and I understand the reasons for the default behaviour of the Pager now. Thanks :)

However, in this specific case I would still give an arm and a leg for a way to append GET parameters to the form that the Pager is POSTing using. So that it can POST to the URL /index.php?flag1=a&flag2=b , for example.

I'm not asking for a change in the default behaviour; but it seems to me that having the option would be useful (for me for sure, and I would wager perhaps others as well).

[2006-03-06 20:01 UTC] remi at metacore dot net

"so why don't you simply use httpMethod=GET?
Or fetch your variables with the $REQUEST array instead of $_GET or $_POST?"

The form search parameters need to be passed as POST data. The navigation parameters that *get you to* the search page need to be passed as GET parameters. It's the standard way that things are done in this instance, and I need to adhere to that. To be perfectly honest, other than problems such as this one with the Pager, it works pretty well.

Standardizing on using $_REQUEST instead of $_GET/$_POST is not an easy thing to do with an existing base, unfortunately... it was easier to make Pager deal with it in a more flexible manner.

"You may either use GET or POST on a single HTTP request, not both."

I agree, but note that you *can* have ?query variables in any absolute URI, as per the HTTP spec -- and that means you can have them in a POST operation, as well. Apache supports it, browser supports it, etc. Pager doesn't yet, though.

Ref: http://www.w3.org/Protocols/HTTP/1.0/draft-ietf-http-spec.html#URI

"Let me know if you still have issues."

As I said, I've already solved the problem by over-riding the Pager object with another... but I believe that this is useful functionality that it would be good for Pager to implement. There's no reason *not* to implement the option to let people specify query (GET) parameters on a POST operation, from what I can tell.

It would make Pager more flexible (and in my case allow me to get rid of the over-ridden object 'hack' that I use to get around it now).

[2006-03-07 01:39 UTC] remi at metacore dot net

I've sent example code. I hope it is enough for you to see the issue.

Not sure if what I am working on is "way out there" in terms of crazy PHP code... it strikes me as surprising that no-one else has encountered this before, to be honest.

It seems a reasonable usage of $_GET and $_POST.

[2006-03-07 01:44 UTC] remi at metacore dot net

To respond to some of your points:

> ok. Again, why don't you use Pager with httpMethod=GET?

... because the HTML QuickForm is targetted as POST and uses $_SERVER['REQUEST_URI'] as it's target action.

> you can, just use the 'fileName' option so it includes
> the GET parameters too...

I tried this before I filed this bug, it is trimming them off for me. If I use the following example code:

$pager = new Pager_Sliding(array
(
'append' => TRUE,
'curPageLinkClassName' => 'current',
'delta' => 4,
'fileName' => $_SERVER['REQUEST_URI'],
'httpMethod' => 'POST',
'importQuery' => TRUE,
'itemData' => $items,
'nextImg' => '»',
'perPage' => 2,
'prevImg' => '«',
'separator' => '',
'spacesAfterSeparator' => 0,
'spacesBeforeSeparator' => 0
));

... where $_SERVER['REQUEST_URI'] is '/index.php?a=search', then the form action attribute is set to '/index.php', *not* '/index.php?a=search'.