I have an issue. I have a list of recipes in my recipes index page. The idea is that when you click on a particular recipe, it carries you to the show page and stores the recipe id in session. The presence/absence of the id in session is integral to the workflow of the program. The session gets cleared when you create a sub-recipe or revisit the index page. However, when you click back on the browser (to recipes/index) without creating a resource, the recipe id remains in session and you no longer desire the value in the session. This causes the program to run into errors. How do I do it that the clicking of the back button also deletes the session
Two possible solutions with the information you've provided:
Set a before_action on the index to clear the recipe id from the session.
Pass the recipe id to the show page via params then set it to an instance variable for use in the view.
I would choose the latter of these if possible. More info would allow a better answer.
So I solved it by checking if the request.referer is the index page's url. If it is, then I clear the session.
Moving forward, you can handle cases like this by checking the header key (request.headers["HTTP_REFERER"]) (also gotten by calling request.referer). This way regardless of the method you used to get to a page, you can always get its fidelity.
Related
I've got a WebFilter that redirects to the login page in my application. In order to redirect back to the referring page I've also added a view parameter called redirectOnLogin which is then used on successful logins in order to perform the final navigation.
If one were to manipulate this query parameter, one could easily provoke JSF navigation errors. I would therefore like to pre-empt this by checking that the outcome is valid but I've not been able to uncover a mechanism for pre-validating a JSF outcome.
Easiest and best is to make sure the redirectToLogin parameter cannot be manipulated. Or that manipulation is detected.
You could solve this in (at least) two ways
Taking the original page name, adding a 'salt' to it and creating a hash.
Addin this has that in the request to the login server
Make sure it is returned by the login server (maybe adding it as # to the return page or as a param.
On receiving it on the 'redirectOnLogin' page, use the page name, the same salt and create a hash in the same way. Compare these and if they match you are fine, if they don't throw an error.
Or you could
Store the 'redirectOnLogin' page in a session to
Check on returning from the login server if it matches with the page you end-up on.
My application feature a "main" page where most of the action happens: There are tags for filtering and a list of results in a (paginated) table, plus the possibility to select some or all results in a "shopping cart".
This page has to keep track of a whole lot of things: what tags are selected, what items are selected, and how the result table is sorted and what page it's on. Everything has to persist, so if I select a new tag, the page must partially reload but remember everything (sorting, what's selected).
Right now I'm handling everything with parameters, and for each action taken on the page, all links (select a tag/item, change page, sort table) are updated to include previous parameters + the relevant new addition. This works, obviously, but it feels kind of inefficient, as I have to reload more of the page than I want to. How is this situation normally handled? I can't find that much info on google at all, but it doesn't feel like a particularly uncommon case.
tl;dr: How to best make sure all links (to the same page) always include everything previously selected + the new action. There are a lot of links (one per tag to select/deselect, one per result item to select/deselect, one per sort option, one per page)
There are five ways to do that:
Method 1: By parameters
You mentioned this. I never think of this as it's too troublesome. Anyway it's still a solution for very simple case.
Method 2: By cookie
Save the settings to a cookie and read the cookie in controller to arrange layout settings.
Method 3: By LocalStorage
Similar to cookie but allows more space.
Method 4: By Session
If you are using ActiveRecord to save session, this could be the best solution for pure pages loading. Save the user preferences into session and load it in next layout.
Method 5: Use Ajax
This is the best solution IMO. Instead of whole page loading, use Ajax to refresh/retrieve changes you need. Using together with above method, a user can even continue his last preferences. This is the most powerful and should be applicable to your case which looks like a web app than a website.
Have you tried creating model for all those attributes? and just always load the 'latest' when on the page load, if you dont need them you can always have a flag for that session.
I have a search page which finds candidates.
From this page you can click view to find more information about the candidate.
When on the candidate view you can click edit or do a number of other actions which would return you too the candidates view.
My problem is from the candidates view I need to add a button to go back to the search results.
I originally thought of using a JS button with history -1 but because the user can do other action from inside the view this won't work.
I am still quite new to rails so not sure of my options... I am thinking some sort of caching of the results and then maybe a hidden field to keep track of the location of the cache(don't think this is the best solution as keeping track of the hidden value could get abit messy!)
Thanks, Alex
I would probably use a session variable to store this information.
First, make sure your form that posts to the search page is a GET operation, this way the search details are in your query string. Then in your search action, you can grab the request URL and store it in the session:
session[:search_results] = request.url
Now in your view for the results, you can do your "Back to search results" like this:
link_to "Back to search results", session[:search_results]
You have a couple of options:
Cache the results, as you've suggested. The potential downsides to this are that it takes memory, and if new valid records get added, you won't see them. You could store the cache in Session, or in the database (though in the latter case, you don't gain much).
I'd suggest just remembering the last search term, either in session or using hidden fields. You end up re-running the query when you go to the search results page, but in a properly indexed DB, that shouldn't be a big deal.
Good luck!
You can include the parameters for the query on the subpage. Eg.: /foo/search?q=stuff displays search result. Each result then has a link like /foo/:id?q=stuff. And on the subpage, you will have the parameter available to link back to the main page.
This solution doesn't use any server side state, which is generally accepted as the better way to build web applications. Not only does it mean that you browser will behave as expected, with respect to bookmarks, multiple tabs etc., but it also ensures that proper caching can be employed. Further, it lowers the complexity of your application, making it easier to debug and extend.
You could put the search results in a "search_results" table keyed by the user id. Then when the user hits the page, always load from a query on that table.
If anybody does come across this page and you need a button that goes back to the previous page and still display those search results (just like the google chrome button), just use :back.....
<%= link_to(image_tag("back.svg"), :back, :class => 'back_btn') %>
Let's say I have a table called positions (as in job positions). On the position show page I display all the detail about the job - awesome. At the bottom I need the prospective applicant to input their professional license # before continuing onto the next page which is the actual applicant creation form. I also need to take that license # and have it populate that field on the applicant form (again on the proceeding page).
I realize there are a couple ways to do this. Possibly the more popular option would be to store that value in the session. I am curious how to do this in the simplest manner?
My idea:
Create a table specifically for license #'s.
Add a small form on the position show page to create license # (with validation)
Store newly created license in session - not sure what to put in which controller?
On applicant creation form populate from session the license #.
This would assume applicants only have one license.
Thoughts?
Appreciate the help!
Don't store this in the session! Pass that as an hidden field.
Let's say the user starts the form, then open the form again in a new window or something... then the session variable would be shared between the two forms. Other problems would occur if the cookie gets removed (session expire, user clear cache...)
This is not good. The best way is using a POST variable. GET works as well but messes up the URL
Seems like a good idea. As for #3, for whatever controller is called in the transition from 2 -> 4, that would be the controller where you store the session, as such:
session[:license_number] = your_license_number_information
From there, it can be called the same way (session[:license_number]) to get it.
The hidden field is safer for data persistence. However is not not then coded in the HTML output? That can be a great data security issue.
This is a trade-off to be considered.
I have a detail page that gets called from various places and has a nice readable url like
"www.mypage.com/product/best-product-ever".
The calling pages (list of products) have a more complex url like:
"www.mypage.com/offers/category/electronic/page/1/filter/manufacturer/sony/sort/price" and
"www.mypage.com/bestseller/this-week".
How can I make a backlink from the detailpage to the calling product list?
I cannot use javascript
I don't want to have the calling page in the URL, because it gets to long
I really want links between pages, no http-post
I cannot use Sessionstate
EDIT:
Sessionstate is ruled out, because if there are 2 Windows open, then they would share the same "Back" page information.
Like Lee said, use the referrer value:
Back
If you don't want the URL in the link because it's too long, try running some sort of simple compression algorithm over the URL, display the compressed data as unicode text and then append the compressed URL as a parameter to a redirect page, e.g:
Back
What about using the referrer header value?
Here's a crazy idea that will require a fair but of work and may not be healthy for performance (depending on your users).. but here we go:
Create a repository for caching 'ListResults' (and wire it to persist to the DB of you like.. or just leave it in memory on the server).
In short what this Repo can do is store a ListResult which will include everything to persist the state of the current view of the list any given user is looking at. This might include routes and other values.. but essentially everything that is needed to redirect back to that specific page of the filtered and sorted list.
As the ListResult item is added to the repo a small unique hash/key is generated that will be url friendly - something like this "k29shjk4" - it is added to the item along with a datetime stamp.
ListResults are only persisted from the moment a list gets off the default view (ie. no filtering, sorting and Page 1) - this will help in a small way for performance.
A ListResult item may never actually get used but all detail actionlinks on the particular list view have the ListResult.Key hash value added to the route. So yes, it might end up as a querystring but it will be short (url friendly) and if you wanna mess with routes more, you can tidy it up further.
For navigation "back" to the list, you may need a new small controller which accepts simply the ListResult.Key hash value and redirects/re-creates the state of the list view (paging, filtering and sorting included) from the lookup in the repo.
So we have met the requirements so far: no calling page in the url (in the sense that its not the whole page - just a hash lookup of it); no POSTing, no sessions, no js.
To stop the ListResult repo from getting to big (and dangerous: if you persist it to the DB), you can use a ASP.NET background service to periodically prune the 'old' routes by way of the timestamp.. and 'extend' the life of routes that are continuously being used by adding time to the stamp of a ListResult item when it's requested via the new controller. No need to persist a route indefinitely coz if a user wants a permalink to a list view, they can bookmark the long list route itself.
hope this helps somehow
Do you have a cookie?
If so, you can put it in there, or use it to create your own session state.
I think this is more like a "Back to results" then a generic "<< back" link, because you would expect the generic back link to return to the genetic list, not the heavily filtered list you described, right?
I don't know if this falls into your "no post" condition, but the only option I can see is having the Detail action be POST-only ([AcceptVerbs(HttpVerbs.Post)]) and include another parameter like string fullRoute which is converted to the 'link' on the detail page for "Back to results". Overload the Detail action missing the fullRoute param and have the overloaded action be a GET action so that the POST fullRoute value is not required (for when users are ok with the 'generic' "Back" link). This should serve both 'generic' GET requests to the Detail page and the POST request which will include the specific "Back to results" link for the filtered list.