A couple paths I can see... 1) avoid the problem. make the task editing modal - either a new window or something like a lightbox. would work well if it was something small, like a 1 or 2 step process 2) change filter to not check the request_uri but instead the session variable or set your own (like @filter = param[:filter] if param[:filter]). then you can add on your index controller action, a set filter session if the param exists
On Jul 7, 9:46 am, Dean <[email protected]> wrote: > This feature has thwarted my many attempts to implement it. > > In my application I have a list of tasks at different progress states > and for different sites and assigned to different users. Users come > onto the system and work on all of the tasks in a particular state, > site or combination of both. > > At the moment I have an index page with a <table-plus> listing of > tasks. Users use the filters to select the subset of tasks they wish > to work on. The problem is that working on each task takes the user > away from the index screen. When they have completed the task and > return to the index screen, their filter parameters have been reset > and they now need to reselect their subset of tasks they are working > on. > > The users would like the filter parameters to remain in use in their > current session until they change them. > > Remembering them is simple enough - just put them into the session in > the controller. The problem is how to restore them. > > Firstly, for each filter-menu, a separate form is constructed for each > filter-menu with the action attribute set to the request_uri so as to > return the filter parameters to the browser. Therefore it is not just > a simple case of restoring the filter parameters from the session - > the request_uri needs to be fiddled with so that the restored > parameters are returned to the browser. > > The next problem is determining if the user is returning to the index > page or just changing the filter parameters. If they are returning > then the filter parameters will be all blank and should be restored > from the session. If they are changing the filter parameters then the > new parameters need to be saved in the session. The gotcha is when > the user changes all of the filter parameters to 'All' ie blank. The > application now thinks the user is returning and restores the filter > parameters, overwriting the users changes. > > I have tried all manner of tricks to detect if the user is returning > to the page but to no avail. As there is only one path back to the > index page I tried modifying the url but because <filter-menu> uses > the request_uri, the modified url gets returned to the browser for > subsequent reuse. I also thought about using a hidden field to flag > updates but the way <filter-menu> implements multiple forms makes it > impossible to insert a hidden field. I could modify the request_uri in > the controller by appending a parameter to it and that modified url > will get passed back to browser for use in subsequent filter changes. > If the parameter is missing then I know that the users is viewing the > page for the first time or are returning from somewhere else. However > that isn't as straightforward to do as it sounds. > > I'm open to suggestions as to how to implement this feature. > > Thanks > > Dean -- You received this message because you are subscribed to the Google Groups "Hobo Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/hobousers?hl=en.
