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.
Related
I'm new to Ruby on Rails. I have a relatively simple question. I'm modeling users. I want users to be able to have a short "profile message" that they can edit and that gets displayed on their profiles. Would it make sense to make ProfileMessage its own model? Or, should profile_message be one column in a table that contains user settings?
I feel like an entire model just for one string is a little bit overkill and if I start going that route, I'm going to end up with so many models that things become cumbersome.
What does the community think?
I would keep your data structure as simple as possible when starting out. For a profile message, it doesn't make much sense to have it be it's own model. Only if profile_message were to later on have it's own set of attributes and behaviors, or if users could have more than one profile message...then I would consider moving it to a separate model.
Table joins in SQL consumes a lot of resources when you are not using them properly. In your case i think that making a new model only for the one profile_message is not a good practice.However, it should be implemented inside the user/profile model.
This approach is going to make accessing the message faster, on the other hand if you are using a whole table for the profile_message will make the response time slower because you will need to look for it every time in the profileMessages table which will take more time depending on the number of entries in that table.
I'm facing a conception problem in developping a website for my videogame.
I have a Model named VideoLink which contain a title, a description and a link to a webvideo (for example youtube).
I have other models such as User, Map, Mission etc.
I want my users to be able to say that a video was made on those maps, during this mission, and those users appears.
I'm wondering if I should go with associations (with has_many relationships) or tagging (with acts_as_taggable_on and 3 attributes maps_list, users_list, mission).
I find associations a little heavy for this as it is a tagging thing not really a relation.
But maybe I'm wrong and tagging could not be the best choice.
Which solution you think is the most relevant to my situation ?
If you have other solutions or questions please tell me, I'm in fact a noob at ror ^^
Thanks for any help.
You would probably get a lot more out if it using associations. If you want to do things like easily generating links to view more details about videolink resources, associations are definitely the way to go. You can do this without associations, but honestly it's a lot less trouble in the long-run if you simply throw a few associations into your models. You could probably build your own tagging solution more specific to your problem-domain easily if you have associations in place for all your models as well. I would recommend taking this option especially so if you're new to ruby on rails, as ActiveRecord associations are an integral part to RoR and it could be a great learning experience. Check out Why associations? for a little more detail on how associations can be useful, the rest of the guide is also a must-read if you haven't already.
If you don't really see value in links and being able to easily query a video for related resources, go with acts_as_taggable_on.
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!!!
I am building small app that will only display products in various categories. And will never display categories without products.
So far I have two models - product and category and wondering if I really need controller dedicated to category model? I can only see one advantage so far - rendering collection (partial) of category. But it could be done via product as well. I want to keep the code as small as possible. Just wondering what is the best approach in such situation, what about routing and resources in rails 3?
Thanks a lot for any suggestions.
I think you should keep the controller for the following reasons:
1) Maintenance of categories, basic CRUD functionality may need to be implemented so this will be required.
2) If anyone else has to maintain the code at a later date it is much easier for them if all the basic details are as expected. Finding a controller missing would probably start to raise a developers suspicions as to what other oddities there will later uncover.
3) How much smaller will not including the controller make it? Its not going to be a vast difference and so for clarity it is probably best to include it.
don't you will need categories controller to add a new category or delete an unused one?
trying to "keep the code as small as possible" at earlier steps often makes your code messed-up at later development steps.
Still in the same topic and CRUD.
It looks like I will not need CRUD for Category model. I am not going to display or manage it as it will be pure static data (still in db) but seeded only once. Therefore what benefit Category Controller would give?
In my app I will only display products inside category - will it be possible without having Controller for Category - I am thinking of valid URLs like /Category/1/Product/1 or even simplifying it to Product/1, Product/2 but still Category is used to navigate between categories.
Any advice or examples?
Thanks
I've just been reading Chad Fowler's blog post about 20 Rails Development No-Nos. On Single Table Inheritance he comments:
The storage of a column called “type” which holds a class name is a pretty good indicator that something fishy is going on. It’s fishy but not always bad. I think, though, that any time you use it you should ask yourself more than once if it’s the right solution. Databases don’t do what they do best as well when you have lots of STI and polymorphic associations.
I'm writing a blog application and I'm considering using STI for the comments that can be made on a post and for the contact messages that visitors can post if they want to get in touch with me. My Message model will inherit from my Comment model. They both share common attributes, except that Message will have an extra subject field. Another commonality is that both will be submitted to Akismet for spam checking.
Rather than just ask myself more than once if it's the right solution as Chad suggests, I thought I'd get some opinions from the Stack Overflow experts as well! Does what I'm proposing sound like a good fit for STI?
I've used STI a number of times. Consider a CMS which might have Page, NewsItem, BlogItem etc.
They could each descend from a common class which in turn inherits from ActiveRecord. The table for each would be the same (title, body, tags, published_at) but each model might have different associations, or different statuses, or a different workflow so each has custom code in their own class. Yet they all share a common table and parent class. It also allow me to use the parent class to do a cross class search and have the resulting Array of records automatically type cast.
There are other ways to tackle this and maybe not the best example but there are certainly times when STI is handy for situations where object behavior may differ but persisted state is the same. Of course you have to be sure this is also true in the future.
In your case comments and contact messages are different. It sounds like there is there no benefit by having them in the same table. Maybe put shared code in a parent class or better still in a module in /lib.