We've got an app that deals with crops like tomatoes, beans, and squash.
One bean, many beans
One tomato, many tomatoes
One squash, many squash
Some of the crops have very weird plural forms, eg. you never pick "one garlic" you pick "one head of garlic". Some are almost never referred to in the singular, eg. "oats" -- you don't plant "one oat".
We use these words in sentences like, "Bob planted 3 tomatoes" or "Mary harvested 3 kg of oats".
So we want to use the Rails inflector to configure some special cases. However, we want to store the details of this in our database alongside other information about crops. Our users will be able to update the record to list the correct singular or plural forms.
We've read up on how to use the inflector but everything suggests configuring it in config/ somewhere, which means we'd have to restart the app for changes to take effect. How can we pick up new inflection information from the database as it changes?
We're using Rails 3.2 but would welcome Rails 4 answers if that's needed, as we're likely to be upgrading sometime soonish anyway.
You can use the 'inflections' singleton to define rules dynamically as you load crops from your database. Assuming you store singular form in an attribute singular and plural in attribute plural...
class Crop < ActiveRecord::Base
after_find do |crop|
ActiveSupport::Inflector.inflections.plural(crop.singular, crop.plural) if crop.singular
end
...
end
And of course you just then use the pluralize method as usual...
ActiveSupport::Inflector.inflections.plural("beatle", "mopheads")
p "beatle".pluralize
=> "mopheads"
Related
I use Ruby on Rails 5.2 and mongoid 7.0
I need to choose a continent by the country
I understand that it should look something like this:
class Place
field :country, type: String
field :continent, type: String
after_save :update_continent
def update_continent
cont = self.country
case cont
when 'United States', 'Grenada'
'NA'
when 'Netherlands', 'Spain'
'EU'
end
self.continent = cont
end
end
Since you indicated you are using Mongoid:
Each Mongoid model class must include Mongoid::Document, per the documentation in https://docs.mongodb.com/mongoid/master/tutorials/mongoid-documents/.
after_save callbacks are normally used for things like creating external jobs, not for setting attributes, because the attribute changes won't be persisted (as the model was already saved). Usually attribute changes are done in before_validation or before_save callbacks. See https://guides.rubyonrails.org/active_record_callbacks.html for the list of available callbacks.
As pointed out by Toby, the case statement is not correctly used. Its result should be assigned like this:
.
def update_continent
self.continent = case self.country
when 'United States', 'Grenada'
'NA'
when 'Netherlands', 'Spain'
'EU'
end
end
You haven't given enough context to be able to answer your question, but since you just want to be pointed in the right direction, and since you seem to be new here I'm happy to give you some pointers.
You're class uses the after_save method as if it is an ActiveRecord Model, but without extending or including anything it's just a Plain Old Ruby Object. To make the after_save callback work you need to at least extend ActiveModel::Callbacks but probably you want to make it a full ActiveRecord Model. To do that in Rails 4 you subclass ActiveRecord::Base and in rails 6 you subclass ApplicationRecord But I don't actually know how it's done in Rails 5.
If you have a normal database in the back end as is usual for rails you don't need to declare the fields, it automatically gets them from the equivalent table in the database (though perhaps this is not true when using Mongoid. I don't know). if you run this command in your terminal in your app base directory: rails generate model Place country:string continent:string it will create the migration file needed to make the database table and the Model file (with whatever the correct superclass is) and you wont need to do all the boilerplate stuff yourself.
You have a variable named cont and you assign a country to it. This will get very confusing given that you also have a separate concept of "continent" Better to not abbreviate your variable names and choose sensible naming.
You're not using the case statement correctly. The output of the statement doesn't automatically get assigned to the the variable you're switching on. You need to read up on Ruby syntax.
Overall I suspect in the long run you would do well to have separate models for Continent and Country. With a Continent having many countries and a country belonging to a continent. Rails is a framework that makes that sort of thing very easy to do and manage. You probably need to read some more and look at examples and videos about the basics of Ruby on Rails.
I highly recommend The Rails Tutorial by Hartl. It's free online. Working through that or an equivalent should give you a much better understanding of how Rails is equipped to handle your situation and how to best utilise it to get the outcome you need. This was indispensable for me when I was first starting out with Rails.
TL;DR: I don't know how organise my logic domain classes.
I have the model "Application", this model is in the "core" of the App and is the way I "enter" and operate over other models like:
#application = Application.find(params[:application_id])
#application.payment.update_attribute 'active', true
or
unless #application.report.status
or
#application.set_income(params[:income][:new_income])
so the models Payment, Income and Report are basically empty because I initialise the Application model and from there I do things "on cascade" to change the "subordinated" models. But now the Application model has more than forty methods and 600 lines.
I'm doing it right? For instance when I want to add a new Payment I like to do :
payment = Payment.create params
inside the Application model because ActiveRecord "knows" how to handle the foreign keys automatically. I could create the payment inside the Payment model using:
application = Application.find(application_id)
params[:application_id] = application.id
self.create params
but this way, I need to set the Application.id manually and that looks more verbose and not elegant.
So --if I want to reduce my Application model--, should I create modules in APP/lib directory or should I move methods to the other models?
should I create modules in APP/lib directory
Basically, yes, that's what you should do. Although I'd probably make them classes rather than modules. The pattern it sounds like you're after is called "service Objects" (or sometimes "use cases"). What this does is takes the logic from a specific operation you want to perform, and puts it in it's own self-contained class. That class then collaborates with whatever models it needs to. So, your models stay quite small, and your "Service Classes" follow the Single Responsibility Principle. Your controllers then usually call a single "service class" to do what they need to do - so your controllers stay pretty minimal too.
If you google "rails service objects" or similar, you'll find lots of great stuff, but here's some resources to get you started.
Service objects rails casts: https://www.youtube.com/watch?v=uIp6N89PH-c
https://webuild.envato.com/blog/a-case-for-use-cases/
https://blog.engineyard.com/2014/keeping-your-rails-controllers-dry-with-services
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ (there's one section on service objects there)
Keep in mind, once you do start using service objects, you don't necessarily have to ALWAYS go through your Application model to get to the related ones. A service object might take an application_id and then do eg. #payment = Payment.find_by(application_id: application_id) and so you don't have to fetch the application instance at all and can manipulate the #payment variable directly.
The fact that Rails makes it "easy" and "pretty" to get to related models doesn't necessarily mean you should do it.
I would not worry about long controller and spec files in Rails.
These files tend to get very long and the usual advice of keeping classes and methods short does not necessarily apply for controllers and their specs.
For example, in our production system user_controller.rb is 8500 lines long and the corresponding user_controller_spec.rb is 7000 lines long.
This is the length of our top 10 controllers
1285 app/controllers/*********_controller.rb
1430 app/controllers/***********_controller.rb
1444 app/controllers/****_controller.rb
1950 app/controllers/****_controller.rb
1994 app/controllers/********_controller.rb
2530 app/controllers/***********_controller.rb
2697 app/controllers/*********_controller.rb
2998 app/controllers/*****_controller.rb
3134 app/controllers/application_controller.rb
8737 app/controllers/users_controller.rb
TL;DR: If your app has four models that are all tied to tables in your database (ie. leveraging ActiveRecord and inheriting from ActiveModel::Base), the framework is pretty opinionated toward using model classes.
Abstractions of the service class pattern can be useful in some cases, but give yourself a break. One of the advantages of Rails is that its supposed to remove a lot of the barriers to development, among many things, by making organization decisions for you. Leverage your model classes.
Let's see if this starts an epic developer bickering war.
Also, its ok to create interfaces in your models for related model creation:
class Application < ActiveModel::Base
has_one :payment
def create_payment(attrs)
payment.create(attrs)
end
end
And by ok, i mean that the framework will allow this. But remember, you're already inheriting from ActiveModel::Base which defines many instance methods, including create.
I would recommend, esp. if this is a small project and you're just getting your feet wet, to use well-named rails controllers to read and write objects to the database:
class ApplicationPaymentsController < ActionController::Base
def create
application = Application.find(params[:id])
application.create_payment(payment_params)
end
private
def payment_params
params.require(:payment).permit(:x, :y) - whatever your attr names are.
end
end
The sleekness you're looking for in abstracting foreign keys in creating a relational record is taken care of for you with Rails associations:
http://guides.rubyonrails.org/association_basics.html (good starting point)
http://apidock.com/rails/ActiveRecord/Associations/ClassMethods/has_one (more explicit docs)
That will help you slim down models if that is your goal. Just for clarification, this is one of those things that devs are extremely opinionated on, one way or another, but the truth is that there are code smells (which should be addressed) and then there are folks who arbitrary preach file length maxes. The most important thing in all of this is readable code.
A good litmus test for refactoring working code is put it down for a few weeks, come back to it, and if its confusing then put in some time to make it better (hopefully guided by already written test coverage). Otherwise, enjoy what you do, especially if you're working solo.
I have a project that is built with a tagging model to reference three different models: artist, article, event. I have associated each model to the tagging model via has_many through:. I have two problems; both related to each other:
I have 5 "default" methods that I wish to be able to call restfully from the tagging controller/model: popular, upcoming, events, articles, and artists. Each method is designed to do exactly as it's name implies. The issue lies within these methods being a query by nature. How can I maintain a consistent schema where 5 of the many taggings models I have require a special attribute (let's call it content) that should subsequently call the appropriate method?
When calling any one of the taggings models, it will return (in it's content attribute) an array of the 3 models specified earlier. Other than adding a method within each model that contains a localized description of the model and then calling upon that type method to match another hardcoded string elsewhere, is there any alternative? I don't like how the implementation I just described requires me to hardcode values. Eek.
I'm very new to Ruby on Rails, so I apologize if this is an obvious solution. However I have spent a week looking into ways to solve this compound problem that I'm trying to solve. Any input is appreciated!
As far as i unterstand you need a polymorphic association. Because tags can be applied on different models, the clue is to treat all these models in polymorphic manner by marking them as :taggable on the association to tags.
I would just use the popular acts_as_taggable_on gem for it.
Tweet to tweets is no big deal.
And I assume Country would become countries without any fuss. I'd even credit them with Cactus becoming cacti (correct me if I'm wrong).
But what if I have class Barnabus? Do I call its table barnabuss, barnabi, or barnabusses?
What about zxzzy? How are non-english words handled?
Are there any non-messy options for overriding the decapitalization and pluralization?
I'm new to Rails and the modified table names have me a bit off-put.
Links to relevant documentation are appreciated. This is the only documentation I have seen relevant to this, and its not helpful for understanding odd exceptions for table names.
Forgive me if this is already covered, the results I got were not exactly what I'm trying to figure out.
String#pluralize uses a heuristic with the rather simple general rules for the English language as a base and adding some known common exceptions.
Using ActiveSupport::Inflector you can customize its behavior.
In Rails projects you can find the inflections config at config/initializers/inflections.rb.
If you'd like to create a Barnabus model with a corresponding barnabi table then all you have to do is uncomment some inflections.rb content and explicitly tell Rails how to treat this word.
ActiveSupport::Inflector.inflections do |inflect|
inflect.irregular 'barnabus', 'barnabi'
end
P.S. Thanks to Holger Just for the edit.
You can trust it for most of the cases but if you have some doubtful model name with awkward plural names, you can always specify the table name in Model. e.g.
class SomeName < ActiveRecord::Base
self.table_name = 'any_name'
end
If pluralization in views/error messages are your concern, in the situation that Rails fails magnificently with pluralizing a tricky table name you can add some localization to your app and tell it what you want it to use under various contexts. See http://guides.rubyonrails.org/i18n.html#translations-for-active-record-models
Here's an example of pluralization rules in action:
activerecord:
models:
barnabus:
zero: Barnabi
one: Barnabus
few: Barnabi
other: Barnabi
I am new to Ruby on Rails. So far, I have only created CRUD operations by using scaffolding. Now, I need to integrate two entities into single form using scaffolding, not by hard coding it.
How can we scaffold two entities together using script?
I have two entities, Student_address and Student_phnumber. I want to scaffold these two entities into a single form where I can do CRUD operations, and I want to achieve this by scaffolding.
Student_address is an entity consisting of Hse_name, Street_name, etc.
Student_phnumber another entity consisting of ph_number, type, etc.
I want to scaffold these two entities together.
Scaffolding is nothing more than a generator set up to model a complete basic resource. There are many other generators, other than scaffolding, that come with Rails by default. None of them are set up to generate resources for a set of related models. I suspect that a large part of this is because of the wide range of methods to express such a relationship make creating a generic UI virtually impossible. Also, scaffolding is more set up to get you up and running very quickly, with the intention of being modified to suit your needs. These modifications are usually fairly involved for any non-trivial application. There are many 3rd party generators out there, including the popular nifty generators, but none that create the kind of code you want to generate, as far as I know. If this is a relationship that you need to set up frequently, you may consider creating a generator of your own to handle the task - it's actually pretty easy. A good way to do it is to implement your ideal case, then create a generator from it.
Edit:
Also, you may wish to adjust your variable/attribute names. They should be lowercase and underscored, so Street_name would become street_name. Arbitrary abbreviations also make it very hard to code/maintain, so Student_phnumber would be better expressed as student_phone_number. The reason for doing this, apart from consistency (ph_number vs Student_phnumber, for example), is that Rails actually uses the casing and spacing in internal methods like these.
Let me see if I understand you.
The model/entity relationship you are describing is:
student
address
- house_name
- street_name
- etc
phone_number
- number
- area_code
- etc
You want to:
a) automatically generate the models
b) automatically generate a controller/view with a form to create a student, including fields to set up the address and phone number
Okay. b) can't be done via a Rails scaffold. You can, however, use the ActiveSupport gem (docs here) to achieve this. Here's what you do:
gem install active_scaffold
rails g active_scaffold Student name:string
rails g active_scaffold PhoneNumber area_code:integer number:integer student_id:integer
rails g active_scaffold Address first_line:string second_line:string student_id:integer
The only manual work you'll have to do here is pop into the models and add the relationships:
Address
belongs_to :student
PhoneNumber
belongs_to :student
Student
has_one :address
has_one :phone_number
What ActiveScaffold will do is automatically produce for you a view like this:
Fill in that form and your models will all be saved and linked together!
Is this what you are looking for?
rails generate scaffold Student student_address:string student_phnumber:string