I'd like to build a simple survey/questionnaire app in Ruby on Rails and wanted to make sure I have the "general" structure correct. The application should allow an administrator to create a new survey and populate it with questions. The answers should pre-populate from a list in the database (e.g. none, a little, somewhat, often, frequently, etc.). Users should then be able to login, select a survey, and complete the questions/answers with their results being stored in a DB.
I've worked out the following scaffolded structure which I will later refactor:
-User
-Survey (has_many Questions)
--Question (belongs_to Survey, has_many Answers)
--Answer_Option (belongs_to Survey)
---Answer (belongs_to Question)
Is that general format correct? I feel like I'm missing something -- perhaps a join table to generate the results? Any thoughts from someone smarter than me? Thanks :)
One thing to consider is, if you really want to re-enter the Answer_Options for every survey. I'd go with a general Answer_Option (or Question_Type) that can be re-used, maybe adding the possibility to create user-generated answer options on the fly.
Related
I have customers and invoices. The users can delete customers, but not invoices.
The problem is when a customer is deleted I can no longer do
invoice.customer.name
Because customer is nil.
I have some solutions on the drawing board
Save some info about the customer on the invoice instance when the
invoice is made.
Not deleting the customer, but hide it from the user with a boolean
field. That way the customer instance is still around.
I know this question might be closed because the answers might be opinionated. Rails is very opinionated on almost everything. On this problem, I have never seen a opinion, so:
What is the rails best practice in this case?
(If you have a better solution I'd like to see it)
If you'd like to set up a deleted_at flag, I'd recommend using the paranoia gem.
https://github.com/radar/paranoia
It is exactly what your second option is and implements all the scopes that you might need.
Your second solution seems to best IMO.
Rather than deleting the customer, introduce a DELETED flag on the customer database (then add it as a default_scope to ignore customers with DELETED = true)
this way you can leave the relationships intact. if you have loads and loads of customers, you might need to think about an archiving mechansim, but I wouldn't worry about that.
Guys I am becoming completely nut on this...and can't figure out at all how come out of all this troubles.
I really need an holy help, or at least some suggestions about tutorial and guides about this problematic.
I believe that this is a very common task in many app, but I can't find nothing that help in this sense, not on stackoverflow, not on google, not on other rails forums that I know...I start to feel like a dumb!!!
Problem
(1) Models (the models that are involved)
User.rb
Item.rb (is nested in user: e.g. user/3/item/5)
(2) What I'd like to do
The current_user (the user that is logged in) can create an Item, and in the same form can decide to share it or no with many other users.
In this way, the item will be visible and accessible also for this users that we shared it with.
I understand that what is going to be involved here is:
(a) has_many :through relationship between item and user
(b) a joint table that we can call sharing (with item_id and user_id)
(c) eventually using different name for the user and use a :class_name to point to user
This is not hard to implement (and there are plenty of examples around).
What is really a mess, instead, is how build the controller (item controller), in order to perform in one shot, the creation of a new item, and the sharing operation (this means setting up the parameter in the joint table, and eventually create as many records as many users we are sharing with - array?)
And the other problem, that obviously is related with the controller, will be the view...how put all this in a single form, and allow the current_user to just click the button, and perform the item creation + the sharing operation?
Last thing, but not the least, how I need to deal with the fact that User is the same model of current_user??
I really don't know what I need to read or look up in order to let this work, I would love to see some example code,but at the same time I'd love to really understand the logic in all this, in order to be able to replicate it in other scenarios.
Please someone help me...I can't really move on in my app development without doing this, and this is also a crucial part of all the project.
Thanks so much for every small bit of help that I will receive.
Ok I have solved all my problems...that was not an hard task at the end (it's always easy saying that when you solved the issue:))
The only doubt that I still have is with the rails name convention:
Can be possible that using a name like sharing, for the joint model, that the final -ing is not very well handled by rails?
After many tentativeness performed to try to fix my problem, I discovered that everything was set up properly, and that just changing the joint table name from sharing to share, let the magic works!!!
First time posting in Stack Overflow, hope I'm doing this right.
I'm writing an app with Ruby on Rails right now. Without disclosing too much, the premise is that we have organizations and normal users. Organizations have events, which require users to answer a questionnaire before participating.
I'm pretty sure about these models / relationships that I will be using (this isn't really that important/pertinent to my question i think, but just wanted to give background):
organization (one to many) events
event (one to one) quesitonnaire)
questionnaire (one to many) users
(specific) response (one to one) user
The part I have a question about is how to implement the questionnaire. I want to give the ability to Organizations to essentially write / build their own forms. I'd like to stay away from them using code if that's possible (ie any DSL and whatnot).
I suppose the easiest way to do this is to give them a set number of text-area responses, so that I can consistently store the data and don't have to hassle around with how to configure storing this data (for example, maybe each event can only have exactly 5 responses to be filled in by textfield response by the user).
My ideal would be for the organization to be able to dynamically generate the forms on their own - maybe one questionnaire will have 1 text input, followed by 3 multiple choices, and maybe 2 short answers at the end; another one may have 5 multiple choices, and 1 short answer; yet another questionnaire might only have 1 text input...you get the idea.
So I see two parts of this problem - the first is the user interface for the organization to create the questionnaire. i'm imagining this wouldn't be terribly hard - ask them how many of each response type (MC, short answer) they would like to put into the form, give them the ability to rearrange them, etc.
The second part of the problem (what I'm more concenred about) is how to store/access this data. I'm guessing there's no dynamic-attribute sort of deal in ruby - storing some field with an unspecified number of parts and whatnot. i suppose i could make them all individual models (ie a question_response model, with :question, :response_type, :response, etc), but I'm fairly certain that's probably inefficient.
My initial guess is probably to serialize the data / use json; I worked briefly with Drupal 6 and this seems to be the way they did it. I was wondering if anyone else had any experience / suggestions though? I'm pretty new to Ruby so I was wondering if there's a gem out there or something that would help with what I'm trying to do.
Thanks!
You might want to look at the Surveyor gem
http://vimeo.com/7051279
*slightly old how-to video
https://github.com/breakpointer/surveyor
Surveyor does come with it's own DSL which is relatively easy to use (although can be abit restrictive at times). The data is saved as a set of question - answer values, so there is no actual specific model (beyond Surveys -> Questions (question_groups) -> Answers).
Originally I did look at having people submit their own Surveyor DSL specs - which would then be used to generate the actual survey via a Rake command.
I think if you need to build a dynamic model (and save the data) it is possible, although I am not not sure if you'll be able to get the Rake tasks to run to build the actual tables in a dynamic way due to permission restrictions.
Have a look at http://ruby-metaprogramming.rubylearning.com/ and Metaprogramming Ruby: Program Like the Ruby Pros by Paolo Perrotta, for some starters.
Ok the scenario is simple(?). I have say Articles, Reviews and Comments, three different models that a user can update. I was wondering what is the best design to follow if I want the updated records (from the user) to become available only to an administrator (and not in a public view) but at the same time the old ones remain as is until the admin reviews them.
First thought was that would be best to have self-referential joins, making a new record on the update action of the user and referencing the old one so that the admin when finishing the review the old record, the latter gets deleted and the reviewed one gets published. I seriously think that if there are many updates from users, then the table holding the data will grow BIG in a very short time. Do you have any other suggestion?
Thank a lot for the help :)
P.S. I am using Ruby on Rails framework, if that makes any different at all..
This kinda reminds me of Wordpress draft system and to be sincere, i think it's probably one of the few ways to do it. That is, have a column with post_type like [draft,published etc..]. Alternatively, you could have a drafts model alone and a published model that are polymorphic of the Article model. I think that you are right in your concerns about a table getting too big. Thus, i think that you would better choose a strategy of removing old drafts or archiving them in another table, so that they just occupy space and not mess with your search time for them (also, remember to use indexes for better performance).
Maybe act-as-state-machine can help as well ( http://www.practicalecommerce.com/blogs/post/122-Rails-Acts-As-State-Machine-Plugin )
One thing to keep in mind is that unless you're trying to create a detailed revision history, there are really only two versions of a given article, view or comment that you need to keep around: The current approved public version of the item and the current edited version of the item. So you can probably just story two copies, and copy the draft version into published and delete the draft when it's approved, or update it if the user makes additional changes before it's approved.
I'm new to rails, so be nice.
I'm building a "rolodex" type application, and this question is about the best way to handle creating an entity along with several relationship entities at the same time.
For (a contrived) example:
My application will have a Person model, which has_one Contact_Info model. On the create.html.erb page for Person it makes sense for the user of my appliction to create the person, and the contact_info at the same time.
It doesn't seem right to include details for creating a contact directly in the create view/controller for person. What's the rails way to handle this?
Using nested attributes is the most common way to do this.
The actual documentation is here.
You want to use "Nested Forms". There is a great example of them in this blog post.
I'm also noob, but I had a similar issue with an app. I was using a tutor at the time and he basically said it was a good example of rails being opinionated. It sounds like you want to take the create action for two different models at the same time, which may be possible but probably very hard. Id suggest considering whether your data model could be modified, or find a way to make an acceptable user flow while collecting the data in different forms.
Update: while writing this the technical answer came in. Keep in mind, its perfectly okay to take the easy route if doing so helps you get the app out the door, and especially while you're still new.