Home » Structures » Structures_DataGrid » Bug #5292

[2005-09-04 12:30 UTC] no_spam at nic dot fi

Description:
------------
For some reason Structures_DataGrid renders header links (for sortable columns) incorrectly. I'm using DataGrid in a subpage which is shown when "subpage" parameter is added. The $dg->renderer->getPaging() method returns html footer that contains the parameter. For example:

main.php?go=a&subpage=b&page=2

However, the header links for sorting the table do not contain the subpage parameter anymore, meaning the sorting doesn't work (link leads to elsewhere).

main.php?go=a&page=1&orderBy=name&direction=ASC

For some reason all my own parameters are stripped from these header links. It would work perfectly if the header links were created just like the footer links are. If I add extraVars to getPaging method, it still doesn't work in _headers_:

$dg->renderer->getPaging('Sliding', '|', '<<', '>>', 5, array('extraVars' => array('subpage' => 'b')));

Adding $dg->setRequestPrefix("subpage=b&"); helps with sorting, but then the paging doesn't work and the url parameter count keeps on increasing...

Is there any way of making the header (sorting) links work just like the footer (paging) links are currently working?

[2005-09-04 13:29 UTC] no_spam at nic dot fi

I found the bug...

In DataGrid/Renderer/HTMLTable.php on line 356:

} elseif (stristr($element, $this->_dg->requestPrefix . 'page') &&

That stristr seems to match all parameters with "page" in them. So, for now I've fixed this by changing my "subpage" to just "sub" and it works. I guess this needs to be fixed in HTMLTable.php?

[2005-09-04 20:33 UTC] post at mark-wiesemann dot de

I think you can use your "subpage" as before, if you give
$this->_dg->requestPrefix a value (there should be a set...() method for this) like "myapp". Then $this->_dg->requestPrefix wouldn't be empty and the stristr won't match your own "subpage" parameter.

[2005-09-05 06:41 UTC] no_spam at nic dot fi

I tried setting the requestPrefix (with setRequestPrefix method, as mentioned in my first report), but it doesn't quite work. If I remember correctly, the prefix was added to every parameter and the count of those kept on increasing. At some point I had a dozen or so orderBy's etc. Also the paging stopped working after setting the prefix. By changing my "subpage" to plain "sub" everything works for me, but this is just getting around the problem, not fixing it.

[2005-09-05 07:40 UTC] post at mark-wiesemann dot de

Ups, sorry I did not see that you mentioned setRequestPrefix.

But I think that this is wrong:
$dg->setRequestPrefix("subpage=b&");

It should be:
$dg->setRequestPrefix("sub");

Please try this and provide an example URL that SDG generates (in the case that this does not work).

[2005-09-05 13:02 UTC] no_spam at nic dot fi

Adding $dg->setRequestPrefix("subpage"); to another page fixed the sorting problem there. The paging seems to work too, so I guess this solves the problem in a way. Though I must say that I'll use the "sub" parameter without setting the prefix, because with requestPrefix set the url looks like this:

main.php?go=reports&subpage=currencies&subpageorderBy=currency&subpagedirection=ASC

I don't like that repeating subpage prefix, so I'll change "subpage" parameter everywhere to "sub" and get around the bug this way.

[2005-09-06 07:46 UTC] post at mark-wiesemann dot de

If you don't like having "subpage" in front of every SGD parameter, why don't you use instead $dg->setRequestPrefix("sub"); or $dg->setRequestPrefix("dg"); or $dg->setRequestPrefix(NAME_OF_YOUR_APP); or something like that?

Please do not forget to close this bug, if your problem is solved. If you don't like the current behaviour, you should change the type to "feature request".

[2005-10-05 01:20 UTC] olivierg at php dot net

There is no reason to use the requestPrefix. This is a bug, "subpage" is not "page" and this stristr() test was bug prone.

I've fixed this, now checking strictly for "page", "orderBy" and "direction".

Can you please test the current CVS to see how it works for you ?

[2005-10-10 23:04 UTC] olivierg at php dot net

This bug has been fixed in CVS.

If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET).

If this was a problem with the pear.php.net website, the change should be live shortly.

Otherwise, the fix will appear in the package's next release.

Thank you for the report and for helping us make PEAR better.