Description: ------------ Hi, When using $dg->setUrlFormat($formatString) the HTML generated by $dg->render(DATAGRID_RENDER_PAGER) is not correct. It is taking the current URL (including /page/6/etc/etc/) and appending this same information. Test script: --------------- $dg->setUrlFormat("/page/:page/orderBy/:orderBy/", "/report/alpha/"); $dg->render(); // no error, links in header look like http://server/report/alpha/page/1/orderBy/col1/direction/asc/ $dg->render(DATAGRID_RENDER_PAGER); // error, href values take current URL as base and add to it. Result for a page 2 link is http://server/report/alpha/page/1/orderBy/col1/direction/asc/report/alpha/page/2/orderBy/col1/direction/asc/ Expected result: ---------------- In this example, link to page 2 should be: http://server/report/alpha/page/2/orderBy/col1/direction/asc/

Hi, I can't reproduce this bug, please verify your test script. How comes your example links contain a direction parameter when your url format doesn't ? I need the test script to be as real as possible.

Hi, Here is exact information. In putting this together now I see the real issue. The actual result is missing the "/" that was supplied in second parameter to setUrlFormat, and which was intended to make the URL absolute, not relative. The actual result is a relative link. Is this bug or feature, and is there a workaround? Many Thanks! Todd Test Script ======= $grid = new Structures_DataGrid(10); $grid->setDefaultSort( array("name"=>"ASC") ); $grid->setUrlFormat("/page/:page/orderBy/:orderBy/direction/:direction", "/report/alpha/"); $grid->bind($this->rows); $grid->addColumn( new Structures_DataGrid_Column('User', 'name', 'name') ); $grid->addColumn( new Structures_DataGrid_Column('Create Date', 'createdate', 'createdate') ); $grid->addColumn( new Structures_DataGrid_Column('Event Date', 'startdate', 'startdate') ); $grid->addColumn( new Structures_DataGrid_Column('Description', 'description') ); $grid->render(DATAGRID_RENDER_PAGER); Expected Results: =========== Link to page 2: href="/report/alpha/page/2/orderBy/name/direction/asc" Actual Results: ========= Link to page 2: href="report/alpha/page/2/orderBy/name/direction/asc"

Okay, verified. This comes from a BC break in Pager from version 2.4.5. I was using 2.4.4 so I could not reproduce it. Todd, what's your version of Pager (please change the "Package Version" up there) ? Lorenzo (Hi :), I'm attaching a patch which contains a new unit test, testAbsoluteLinks(), that works in Pager 2.4.4 but fails in 2.4.5 and 2.4.6. Hope that helps

Hi Olivier, that's probably due to this bug fix: http://pear.php.net/bugs/12306 Since 1.4.5, if you explicitely set 'path' to an empty string, then the link is made relative. That's easy to circumvent: change ------------------------ 'path' => '', 'fileName' => '/report/alpha/page/%d/orderBy/foo/direction/asc', ------------------------ to ------------------------ 'path' => '/report/', 'fileName' => 'alpha/page/%d/orderBy/foo/direction/asc', ------------------------ I don't know how to preserve relative links otherwise... if you have some ideas, I'd be happy to hear them, really.

Okay, I see. Trouble is my URL is generated with Net_URL_Mapper, and I've almost no idea of what it contains. So I've implemented the following workaround in SDG_R_Pager: if (substr($options['fileName'], 0, 1) == '/') { $options['path'] = '/'; } else { $options['path'] = ''; } But the generated link is still relative.. Same thing happens if I set 'path' to '/' in testAbsoluteLinks() Is it expected ?

yes, the trailing slash is removed from _path to avoid double slashes when joining it with _fileName. What if you set the path var to the host? Can you do that?

I don't like that, it's intrusive, I'm gonna have to take care about protocol, port, etc.. (eg: https://foobar.com:8080), and all in all it's gonna make an ugly output. I feel like it's quite a limitation not to be able to generate an absolute url unless you use a hardcoded "path". Could you add an option for this maybe? You already have the unit test ;)

if you see the other bug report, that's what I had originally planned. Anyway, I'll see in the next few days if there's a way around it, otherwise I'll add an option. And thanks for the test case! :-)

Okay, I read bugs #12306 and #2617. Here's how I believe the whole thing, which looks like a design issue, could be fixed: 1 - obsolete path, fileName and append options, keep them hidden for BC 2 - create a new "url" option which defaults to ":(self)?:(vars)" for GET, ":(self)" for POST, and could contain any of: - :(page) : the page number - :(self) : $_SERVER['PHP_SELF'] - :(script) : test.php in foo/test.php - :(urlVar) : the value of the urlVar option - :(extraVars) : the extra arguments - :(vars) : ":(urlVar)=:(page)&:(extraVars)" - others when/if needed... 3 - when building the url, replace these tokens, suppress any trailing "?" and "&" and do nothing else (do not touch slashes) For bug #12306, url would be ":(script)?:(vars)" For bug #2617, it should work with default url (?) For this bug, the url would be dynamic and contain :(page)

Okay, my idea was for url generation but I forgot parsing... Just forget it. So here are my last thoughts: In bug #12306, which resolution caused a BC break in my case, the initial sentence "sometimes I want have only relative links, without an abs_path and only a filename." is caprice to me, not need. AFAICS, it only affects the html source, not urls the links point to. I suspect that if you revert this change, Carsten's scripts will continue to work unmodified. The difference is cosmetic IMO. In bug #12306, I see no argument against this point of view.

OK, I think I managed to kill two birds with one stone. Can you fetch the latest CVS version and reopen this bug report if you still experience this issue?

Works great. Thanks