Open gedtn opened 8 years ago
adam-buckley
commented
8 years ago Sounds good! Off the top of my head, you could also append $_SERVER['QUERY_STRING'] to the $_SEVRER['REQUEST_URI'].
That or we move to persisting all filter arguments to session.
gedtn
commented
8 years ago Even better...
Agree that we should persist all the filter arguments, but that would be a lot more involved, where this could be a quick win. I have already tested it and it works nicely.
A point raised is that the history label will be 'LIST TASKS', and you could have a few in the breadcrumbs without being able to differentiate between them. Would it be possible/practical to have alt text? Difficult to overcome all potential issues with limited real estate.
adam-buckley
commented
8 years ago I wouldn't store multiple history instances for the same page, even though the get parameter may be different, the user will be expecting to go back to the last version of that page.
On Thu, Jan 14, 2016 at 2:20 PM, gedtn notifications@github.com wrote:
Even better...
Agree that we should persist all the filter arguments, but that would be a lot more involved, where this could be a quick win. I have already tested it and it works nicely.
A point raised is that the history label will be 'LIST TASKS', and you could have a few in the breadcrumbs without being able to differentiate between them. Would it be possible/practical to have alt text? Difficult to overcome all potential issues with limited real estate.
— Reply to this email directly or view it on GitHub https://github.com/2pisoftware/cmfive/issues/177#issuecomment-171518146.
syntithenai
commented
8 years ago request URI, get query string, timestamp
Sounds good
I think that's enough information to implement search form persistence
function index_GET() { // restore search criteria if ($_GET[''reset"]!=1 && $_GET[''search"]!=1) if (History::URIMatchCurrent() ) { // if the uri matches (all requests to this action) History::redirect() // HTTP redirect to same URI with stored query string } } History:add(); // do search }
maybe tack on &search=1 to dodge looping
S
On Thu, Jan 14, 2016 at 2:23 PM, Adam Buckley notifications@github.com wrote:
I wouldn't store multiple history instances for the same page, even though the get parameter may be different, the user will be expecting to go back to the last version of that page.
On Thu, Jan 14, 2016 at 2:20 PM, gedtn notifications@github.com wrote:
Even better...
Agree that we should persist all the filter arguments, but that would be a lot more involved, where this could be a quick win. I have already tested it and it works nicely.
A point raised is that the history label will be 'LIST TASKS', and you could have a few in the breadcrumbs without being able to differentiate between them. Would it be possible/practical to have alt text? Difficult to overcome all potential issues with limited real estate.
— Reply to this email directly or view it on GitHub <https://github.com/2pisoftware/cmfive/issues/177#issuecomment-171518146 .
— Reply to this email directly or view it on GitHub https://github.com/2pisoftware/cmfive/issues/177#issuecomment-171518436.
Steve Ryan Software Engineer stever@syntithenai.com phone (mobile) 0423 083 685 phone (SIP) 61262237142 skype : irishflute 260 Spring Creek Road Buckajo NSW 2550 Australia
The opportunity
When adding history, the History::add only picks up $_SERVER['REQUEST_URI'], which does not include any page arguments, such as filters. One example was listing tasks from task group, the group id was in the url as an argument, but the history was task/tasklist, so when you clicked on the history the task list is not the original view.
Proposal
Add a new optional parameter to History::add, where you can supply the arguments for the page. In the case of viewing tasks from task group, the tasklist would be able to determine the nature of the view, add an appropriate description to the history as well as the page args. The key is to be able, where required, differentiate between different views of the the same page, so you would need to make sure that views with args are appropriately identified (in the history label).