[jira] Updated: (TAP5-1358) GridPager links need to send page's request parameters

["Geoff Callender (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoff Callender updated TAP5-1358:
----------------------------------

    Description: 
GridPager's page uses EventLink, but EventLink has a problem: even though it DOES send the page's activation context (which is good), it DOESN'T send the page's request parameters (which is bad)!  

Does this happen in 5.2 too?

This is a real problem since I like to put search/filter criteria into request parameters and not the context. The problem is that when I click on a GridPager link I lose the search/filter criteria. Why do I use request parameters for search/filter criteria? Because it is arguably more RESTful. See 

    http://jumpstart.doublenegative.com.au/jumpstart/examples/state/passingdatabetweenpages1
    http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/

Example

A page has enterable search criteria fields (name, department, status). 
Type in a name and submit the page. We redisplay with the Grid populated and more than one grid page.
If the page puts the search criteria in the activation context then the GridPager's link to page 2 looks fine - like this...

        http://localhost/myapp/things/index.grid.pager/2?t:ac=jack/$N/ACTIVE

...however if the page puts the search criteria in the request parameters, then the GridPager's link to page 2 looks inadequate - like this...

        https://localhost/myapp/things/index.grid.pager/2

...but to prevent losing the request parameters it should be like this...

        https://localhost/myapp/things/index.grid.pager/2?name=jack&status=ACTIVE

I wasted a lot of time figuring out this was what was going wrong, even though I could see this what was happening, because I was refusing to believe that request parameters weren't getting equal treatment in this situation!


  was:
GridPager's page uses EventLink, but EventLink has a problem: even though it DOES send the page's activation context (which is good), it DOESN'T send the page's request parameters (which is bad)!  

Does this happen in 5.2 too?

This is a real problem since I like to put search/filter criteria into request parameters and not the context. The problem is that when I click on a grid pager link I lose the search/filter criteria. Why do I use request parameters for search/filter criteria? Because it is arguably more RESTful. See 

    http://jumpstart.doublenegative.com.au/jumpstart/examples/state/passingdatabetweenpages1
    http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/

Example

A page has enterable search criteria fields (name, suburb, status). 
Type in a name and submit the page. We redisplay with the list populated. Each row has an EventLink labelled View. 
If the page puts the search criteria in the activation context then the grid pager's link to page 2 link looks fine - like this...

        http://localhost/myapp/things/index.grid.pager/2?t:ac=zac/$N/ACTIVE

...however if the page puts the search criteria in the request parameters, then the grid pager's link to page 2 looks inadequate - like this...

        https://localhost/myapp/things/index.grid.pager/2

...but to prevent losing the request parameters it should be like this...

        https://localhost/myapp/things/index.grid.pager/2?name=zac&status=ACTIVE

I wasted a lot of time figuring out this was what was going wrong. The reality was staring me in the face but I was refusing to believe it because it seemed ridiculous that request parameters weren't getting equal treatment in this situation!



> GridPager links need to send page's request parameters
> ------------------------------------------------------
>
>                 Key: TAP5-1358
>                 URL: https://issues.apache.org/jira/browse/TAP5-1358
>             Project: Tapestry 5
>          Issue Type: Improvement
>          Components: tapestry-core
>    Affects Versions: 5.1.0.5
>            Reporter: Geoff Callender
>
> GridPager's page uses EventLink, but EventLink has a problem: even though it DOES send the page's activation context (which is good), it DOESN'T send the page's request parameters (which is bad)!  
> Does this happen in 5.2 too?
> This is a real problem since I like to put search/filter criteria into request parameters and not the context. The problem is that when I click on a GridPager link I lose the search/filter criteria. Why do I use request parameters for search/filter criteria? Because it is arguably more RESTful. See 
>     http://jumpstart.doublenegative.com.au/jumpstart/examples/state/passingdatabetweenpages1
>     http://blpsilva.wordpress.com/2008/04/05/query-strings-in-restful-web-services/
> Example
> A page has enterable search criteria fields (name, department, status). 
> Type in a name and submit the page. We redisplay with the Grid populated and more than one grid page.
> If the page puts the search criteria in the activation context then the GridPager's link to page 2 looks fine - like this...
>         http://localhost/myapp/things/index.grid.pager/2?t:ac=jack/$N/ACTIVE
> ...however if the page puts the search criteria in the request parameters, then the GridPager's link to page 2 looks inadequate - like this...
>         https://localhost/myapp/things/index.grid.pager/2
> ...but to prevent losing the request parameters it should be like this...
>         https://localhost/myapp/things/index.grid.pager/2?name=jack&status=ACTIVE
> I wasted a lot of time figuring out this was what was going wrong, even though I could see this what was happening, because I was refusing to believe that request parameters weren't getting equal treatment in this situation!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.