My goal is to ask a series of questions. Kind of like flashcards. I have the questions in a table, and I can load them into a hash and ask them at random. The problem is that I want to be able to ask a particular question once per review session. The problem I have is that as soon as the page loads I lose the history and the hash resets to all the questions. How do you solve this using (just) Rails? I know the answer is probably "use JavaScript" but was wondering if it was possible using pure Rails.
One solution I thought of was creating a temp table and pulling all the questions there, and then deleting the question as soon as it's asked. Is that the best solution?
Just use rails session to store information about your survey between requests: http://www.justinweiss.com/articles/how-rails-sessions-work/.
Related
I'm a beginner for rails application, I have troubled some issue which is display related post, I already show post separately according to id I have not any idea how to show related post.
Below my code for show post separately according to id:
def postDetails
#details= Post.find(params[:post_id])
end
Now how can I rich this solution?
This is not an answer, so I'll delete if required.
--
Your question is highly ambiguous, meaning that it's open to interpretation in many different ways. Whilst not a problem, when it comes to application functionality, you need to be as specific as possible.
Contrary to the new buzzwords of "full stack engineer", "devops" etc - the core of computing is to design functions & algorithms which "compute" data. Your case is exactly the scenario where a professional developer would outline a spec, and work towards implementing it.
To answer your question as broadly as you asked it, you have to define how you wish to "relate" your posts.
There are several options (all involve data sampling) --
define each post by "tags" or similar categorization
create an algorithm to parse the title, pull out keywords & search for them
have users specifically define which posts are "related"
As you can see, there is one constant with the above - you need a "benchmark" to associate data. Be it keywords, tags, associated posts - you have to be able to identify the data you want.
Thus, you'll have to define the pattern you wish to employ. I can talk through each option; it would be too much to write without knowing how you want to do it.
I'm trying to develop page for displaying survey questions on a mobile view using mvc. I have to display one question at a time and on clicking next it should display next question.
Am having hard time to achieve this. I initially thought I could using paging, as all the questions are inside a List collection. but then I get struck on how to save the answers selected by user for each questions. From performance side its wise to send a collection back to business layer to save all the selected answers to DB rather than one at a time.
For desktop browser I displayed all the questions on single page and one submit button at the end of the page. So on there is no issue with this one. Problem arises with mobile view.
So could someone please suggest on how to achieve this.
Thanks in advance,
Sai
From performance side its wise to send a collection back to business layer to save all the selected answers to DB rather than one at a time. - i dont think it would be much of a performance issue.
still.there are multiple options for the work you wanna do.
Use cookies as the storage mechanism - this way answers can be stored as key values pairs key being the index of the question.
this way every time you request a new question using ajax via jquery or simpel post back you can you can set cookie to the answer you have got.
save it at server side using session storage same as key value pairs.
use HTML 5 storage.
you can use this to store data at client side using jquery
I would store the questions in a database. Then each user, if the site is accessed via a mobile device (could detect via JavaScript) you would then save a field in their info (in the database) containing the index of the question that they're up to. I think this is a good idea as it would work cross device, if they start on a phone, then move to a tablet, their 'session' will still persist. Then when they're up to the next question, change the index, and query the database using the user's question index for the relevant information to produce the question.
I have a Rails Application where I want to present user with a sequence of Questions in a particular order. A user cannot proceed to the next question unless he has answered the previous one.
Here are some design issues I need help on for an efficient implementation:
To fetch a list of questions for a user I need to make an expensive
db call. Once for a new session, the list if fetched I simply want the
user to see the questions in a particular order starting from the
first question. If the user had attempted some questions in
a pervious session he will jump to the question he last left off. How
to implement it efficiently? I believe I need caching here.
On rendering the views :
How to render the view for this feature? I can have a controller with
the initial question template. When user attempts the question, should
I have question-answer options text updating with AJAX? Do I have to
use jquery for the purpose or any Rails helper could be of help here?
Any design help, rails features-gems I could make use of will be welcomed.
My answer is not specific to Ruby on Rails, but it should still work.
First I wouldn't load data that you potentially won't use in advance. If you have 10 questions, and you only show one at a time, then I would just load the first and then once the user has finished the first, go ahead and load the second. No need to load all ten because maybe the user never makes it to question 10.
Assuming the user leaves pre-maturely, you can just make an AJAX call to pick up where you left off.
I would agree that you should cache those questions though.
The steps would look like this then:
First question - loaded via AJAX. Answer and progress saved via AJAX call.
If (1), then second question loaded via AJAX. Answer and progress saved via AJAX call.
Repeat until questions done.
This way you can use user/login information to make an AJAX call to pick up where you left off. I would imagine this would make your database calls much less expensive.
Apologies in advance as I'm sure this topic has no doubt been asked before but I couldn't find any post that answers my specific query.
Bearing in mind that I'm new to MVC this is where I have got to. I've got a project developed under VS 2010 using the MVC 3 framework. I've got a search page which consists of 6 fields and a nested model which itself holds around 3 fields.
I can successfully post all this data back to itself and the data is successfully passed as a model and back agian so the fields keep the data which the user has supplied.
Before I move on to actually using this search criteria on another view a thought hit me. I want to keep this search criteria, and possibly even the search results in memory for the duration of the users session.
The reasoning behind this is simply to save my users time by:
a) negating the need to keep re-inputting their search criteria regardless of how they enter or leave the search page
b) speed up the user experience by presenting the search results more quickly
The later isn't as important as the first requirement.
I've done some google searches and indeed had a look through this site on similar topics. From what I've read using sessions (which I would typically use if developing a PHP site) is a no no. From the reasons I've read as to why you shouldn't use sessions seem valid and I'm happy to go along with it.
But now I'm left in a place where I'm scratching my head wondering to myself what exactly is best practice to achieve this simple goal that could be applied to similar situations later down the line in the project.
I also looked at the OutputCache method and that didn't behave as I expected it to. In a test I set the timeout for 30 seconds. After submitting a search I clicked the link to my search page to see if the fields would auto-populate, they didn't. But then clicking the search button the values in the cache were retrieved. I thought I was making progress but when I tried to submit a new value the old value from the cache came back i.e. I couldn't actually change my search criteria with the cache enforced. So I've discounted this as an avenue to explore.
The last option seems to suggest the use of cookies as the most likely candidate, but rightly or wrongly I feel this isn't the best solution. I would have thought the MVC 3 design pattern would have an easier and recommended method of persisting values. I'm sure there is but I've just not discovered it yet.
I have started to use JQuery and again this has been mentioned but I'm not sure this is right direction to take either.
So in summary my question really comes down to what is considered by the wider community as best practice for persisting data in my situation. Effiency, scalability and resiliancy is paramount as I'll have a large global user base that will end up using this web app.
Thanks in advance!
Pete
I'd just use cookies. They're simple to use, you can persist them for as long as you want or have them expire when the users closes their browser, and it doesn't sound like you are storing anything sensitive in them.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I know you should use POST whenever data will be modified on a public website. There are several reasons including the fact that search engines will follow all the links and modify the data.
My question is do you think it is OK to use GET behind authenticated pages in something like an admin interface?
One example would be a list of products with a delete link on each row. Since the only way to get to the page is if you are logged in, is there any harm in just using a link with the product ID in the query string?
Elaboration for comments:
I personally don't have any issues or difficulties in implementing the deletes with POST. I have just seen several examples of code in ASP.NET and ASP.NET MVC for "admin like" pages that use GET instead of POST. I am curious about peoples' opinion on the matter.
The temptation of using GETs is that you can create a bunch of delete links without creating dozens of forms per page, or resorting to JavaScript. Yet for various reasons that have already been mentioned, the web depends on GETs not being destructive.
The best practice, if generating one tiny form per delete link in on server is impractical, is to use a GET link to load up a confirmation page from the server which has a POST form that performs the delete. Then do some progressive enhancement:
Delete
If the server gets a GET to /controller/delete/x then serve up a confirmation page with a POST form. If the server gets a POST (or maybe a DELETE) request then do the deletion.
Some people learned some time ago that it's a very bad idea.
Google launched a new app to "speed up browsing" (Google Web Accelerator) that prefetched the linked pages in the browser (no attacks, no third party...), and when someone logged to such protected pages, well the app looked at all those links and said: "Hey, I'll prefetch those ones also because that way I have the page ready when the user requests it"
They have changed the behavior, but anyone can do anything similar any day.
It is still bad practice to use GET for destructive operations - even if it is hidden behind authentication - as it makes it possible (easier?) for someone with knowledge of that URL to exploit it (for example, using XSS). And of course, it is a bad design/coding practice as well, especially if you are trying to create a RESTful service.
There are probably many other reasons as well...
GET ought to be used to retrieve data idempotently and POST ought to be used to update data non-idempotently. That's all. It's certainly not a "best practice" to interchange the methods.
As to XSS and CSRF risks, to prevent the one just HTML-escape any user-controlled input during (re)displaying and to prevent the other just make use of request based tokens and/or captchas.
Yes.
Code may rely (correctly) on GET not being destructive. That code could run in the browser, and thus will be authenticated (link prefetching comes to mind).
It would be a bad practice to delete data based on a GET request. Technically, you can do it, but you'll be out of sync with most well written websites. You are basically creating a new set of rules for your user interface if your use GET requets for deletes. I consider the URLs of your website part of the user interface. If you sent somebody a link like http://www.fakesite.site/posts/delete?ID=1, they would expect to be displayed a page asking if they want to delete post with ID #1, not perform the actual delete.
I do this on pages where I know someone is logged in and I can verify the users right to delete something based on other data which I keep in my session. I would suggest adding a confirmation step: "are you sure you want to delete this thingy?"
GET and POST are very, very similar except for the fact that GETs have a limit on the length of the HTTP action because they are all URL based.
Since you won't be providing access to people who haven't authenticated I don't believe using gets is problematic.