In Ruby on Rails 3, I can't scaffold a model called Data. I can make the Data controller but I can't make the Data model. It has to be UserData or something along those lines.
Ruby on Rails says, it is being used already (my guess is) by the gem itself.
Am I the only one getting this?
How come I cannot create the model name to be Data only?
I think your problem is that there is already a Data class in the Ruby standard library (both 1.9+ and 1.8.7). The Data class is only defined in one of the C source files but it is still publicly visible. I'm not sure what the Data class is for (and the documentation is rather sparse) but the name is already in use so Rails won't let you use it. You can make the controller easily enough because the controller will be DataController and that name isn't taken.
Related
In rails/activerecord, is it possible to have three ruby classes, two of which inherit from one main class, and then have two separate tables for pots and pans. Like so...
class Tupperware < ActiveRecord::Base
end
class Pot < Tupperware
end
class Pan < Tupperware
end
and the advantage would be that I could use the Tupperware.find() method, and a few other things, without having to customize for each different type.
I know for sure it works with mongoid – I've done it myself a couple of times. I'm not sure if this would work in relative database engine...
But you're actually asking a question you could answer yourself, by just trying to do what you said.
[In response to OP's comment]:
I'm just saying you should do a test rails application using a relative db, such as mySQL or SQLite and define your models exactly the way you think.
I have an abstract model I use in my application. It's working perfectly and the find() method works just as you'd expect, but I'm working on Mongoid, so I don't use ActiveResource and can't say for sure if this will work for you. The only thing you can do is try.
Here, take a look at this excerpt from my code:
https://gist.github.com/ellmo/5262681
I'm hoping I can get some help with a mass assignment issue in my recently upgraded Rails 3.2 app.
I understand that in Rails 3.2 attributes are locked down by default and in order for them to be assigned I need to "unlock" them using attr_accessible. This works fine for normal model attributes.
However, I have a homegrown custom property mixin that allows me to add arbitrarily named properties to any model. These properties are stored in the custom_properties table. This mixin leverages method missing to look for a property from that table if I ask a model for a property like: foo.property_foobar.
Each model that uses this mixin can have X custom properties with arbitrary names. I don't have the ability to dictate the names of these properties which obviously makes it difficult to add to attr_accessible.
Does anyone have a recommendation on how I can allow mass assignment of these dynamic properties? I would rather not whitelist all model attributes.
Hopefully all of this makes sense. Thanks everyone!
Louis
One solution is to use attr_protected instead. This allows you to blacklist some attributes while allowing the rest. However, this is a bit harder to secure.
Another solution is to move assignment protection to the controller and allow/reject attributes as needed in each controller/action. There is a gem called strong parameters that allows this and it will also be included in Rails 4. I suggest this solution.
If none of the above work for you, maybe you should try another approach to implement those arbitrary attributes? For example, you could instead store them as a serialized hash in a database column.
I am currently going through Hartl's Rails Tutorial, and through the first 10 chapters or so have gotten used to the convention of putting most of the actions/methods in the controller. Currently, as the book is going through and defining a feed method for the Microposts, the method is placed with the User.rb model instead. As I am relatively new to the world of rails (and programming in general), I was wondering what the rationale or convention followed for putting this method (copied below) in the Model?
The method placed in the User.rb model:
def feed
# This is preliminary. See "Following users" for the full implementation.
Micropost.where("user_id = ?", id)
end
There is actually quite some contention on what code to put where, but in general, there are some easy guidelines to follow.
Does the method have to know some detail about the underlying data structure? Put it in the model.
An easy way to determine this is when it uses ActiveRecord methods like find, where, or specific columns in the database. By keeping this logic in the model, that means if you need to change the underlying datastore, you only have to change the model.
Does the method have some say in how a page is going to be rendered? Put it in the controller.
Generally, controllers should be pretty thin, pushing data to views and saving form data back to models.
While (if I remember correctly) Hartl does not take about non-rails classes, don't be afraid to put 'business logic' outside of the rails structure. You can create a app/lib or app/services or app/x directory and put plain old ruby objects in there, which can then be called from your controllers and models to handle those things they are good at.
Aim to 'push' things 'up' into the model as much as possible, then they will be repeated less and available to more. Don't just use models for Active Record database tables.
You can often unit test models easier.
Another 'next' place to put stuff that is shared is in /lib
For example: Let's say I'm grabbing a list of names and saving it to an NSMutableArray. Do I implement the method of actually calling the server to fetch the data in the controller (UIViewController) or the model(Friends object)?
It's a design decision that depends on what you're trying to accomplish. If your model only makes sense in the context of a single service, or if you want your model to provide access to all the data on the server, then build the connection to the server into your data model. This might make sense if you are, for example, building a client for a service like Twitter or Flickr.
On the other hand, if you're just grabbing a file from a server and that's the end of it, it may make sense to do the communication in the controller. Controllers tend to be less reusable and more customized for the particular behavior of the application. Keeping the specifics about where the data comes from out of the model makes the model more reusable. It also makes it easy to test -- you can write test code that just reads a local file and stores the data in the model.
That's a good question. I think the best way is through a controller because it decouples your model from requiring the other model to be present for it to work properly. Although I don't think you violate "proper mvc" by doing it in the model either.
I think you want to put it in the model. What you'll do is interrogate the model for the data and then the model will handle how to populate itself whether it's from an internal data store or an external one (like a server).
One approach is to use the repository pattern. To do this, you create Repository objects in your Model folder and you place all of you database-related methods in them. Your controllers call the repository classes to get the data. This allows you to separate the real model objects from the database accessing methods.
I use the MVCS pattern (Model-View-Controller-Store), which I discovered in Aaron Hillegass's book "IOS Programming: The Big Nerd Ranch Guide" (http://www.bignerdranch.com/book/ios_programming_the_big_nerd_ranch_guide_rd_edition_)
The store is specifically designed to fetch the data, whether it comes from a server, a local file, a persisted collection, a database, etc.
It allows to build very evolutive applications. For example, you can build your application based on a web service, and the day you want to persist your data, you juste have to modify the store, without having to modify a single line of code in your controller.
It's a lot like the Repository Pattern (http://msdn.microsoft.com/en-us/library/ff649690.aspx) (cf BobTurbo's answer)
I'd personally make a DAO, or data helper class. It's very hard to follow the strict MVC in objective C when things get more complicated. However, putting it in the model or the VC is not wrong as well.
This is a complicated question with many possible answers, so I'll break down my situation into simple bullet points to help narrow down the solution:
My Rails App Has the Following 'Objects'
Author
Feed
Update
FeedTypes
The Objects are Related Like So:
Authors can have 1 or more Feeds
Feeds can have one or more Updates
A Feed has one feedType
Example Setup:
Author: Levi Hackwith
Feed: view-source:http://www.twitter.com/statuses/user_timeline/opnsrce.xml
FeedType: Twitter
Update: The tweets inside the Feed
My problem and My Questions:
Problem:
I need to parse the above-mentioned feed and store each tweet in the updates table. To parse the feed, I was thinking of writing a custom Feed class which would get inherited by TwitterFeed, FacebookFeed, TumblrFeed, etc.
However, I'm not sure if this is the 'Best Practice' for solving this kind of problem.
Questions:
When is it appropriate to develop a custom class to perform an action in RoR (as opposed to going through the Model or Controller)?
If this situation does not call for a custom class, which element should I apply the parsing logic to? The model or the controller?
If this is an appropriate situation for a custom class, where in my rails application should I store it (in other words, what's the right 'convention')?
You are probably going to have a background task invoked from time-to-time to check all the feeds, fetch new updates and store those in database. This task is completely separate from controllers and it should be possible to invoke it without any controller logic.
Your abstraction looks fine. You can further have something like XmlFeed < Feed if several feeds share a common XML structure.
1) Controllers should talk to database/models and pass relevant data to the view to render. Everything else should be either in a model, helper or library.
2) Are you asking where the parsing logic belongs to? In MVC, I think this would belong under the Model and/or a helper class, but definitely not the controller.. it's not its responsibility.
3) Classes holding data go into app/models. Classes that have nothing to do with holding data, go into the lib directory.
Don't shy away from using a custom class if it's appropriate. If you need another a class, then add one, the fact you are using rails is not relevant to that decision.