When coding with PHP I always separate configuration values like perPage value in a separated ini file. How are you Ruby masters do this with Rails?
I would like to access config values inside my model, controller and view.
Thx!
I've generally just used a plugin like http://github.com/cjbottaro/app_config or wrote my own. I like using a config.yml file in the config directory.
There isn't really anything built in to rails to do this, but luckily there's a great plugin called settingslogic which lets you externalise your settings.
Having said that I personally like to make these things constants in my model, so for example I'd have something like this:
class Person < AR:B
DEFAULT_PER_PAGE = 10
end
Not sure about masters :) but mortal developers can usually leverage some of the existing plugins like this one: http://www.workingwithrails.com/railsplugin/5324-app-config
There are actually quite a few of them, so you'll probably find something that will suit you.
Related
I working on json file format in rails.
I like to use environment in config/databse.yml (or better place) to define what json file to use in the app.
But have no idea, unable to find any sample.
Any help please.
Existing code in helper as follow
def get_table(foo)
get_data = if [:production, :sandbox].include?(Rails.env)
File.read("support/product.json")
else
File.read("support/sample.json")
end
JSON.parse(get_data)
end
If I understand you correctly then you are trying to load a JSON file based on the current environment? I'm not sure a JSON file is really the kind of data store you are looking for... but that is a different question.
In your case, I would use an environment variable to set the file name that is to be used during the execution of the application.
Change the helper to something like:
def get_table
database_content_from_file = File.read(ENV['database_file'])
JSON.parse(get_data)
end
You can now set the environment variable 'database_file' in each of your different types of environments. This can be done by setting a system-wide variable or using a gem like https://github.com/laserlemon/figaro (which I highly encourage you to use).
With this, you could set ENV['database_file'] to 'support/sample.json' in your development environment and set it to 'support/product.json' in production.
I hope this answers your question. If not please rephrase your question in a manner that is easier to understand.
In a Ruby on Rails application, where would the most logical place be to put a "file flag."
I am attempting to externalize configuration and allow the presence of a file to be the deciding factor on whether or not something shows on the webapp.
Right now, I have a file here:
lib/
deployment_enabled
Model deployment.rb
class Deployment...
...
def deployment_enabled?
Dir["#{Rails.root}/lib/deployment_enabled"].any?
end
end
Now this works of course, but i'm not sure this follows the MVC paradigms, since the lib directory should consist of scripts. I could put it in config, but again - not sure it belongs there as rails uses this for rails specific configuration, not necessarily the webapp.
I could of course put this in our database, but that require a new table to be created, and that seems unnecessary.
Where's the most logical place to put this flag file? Does Rails have a directory that's created during the generation to put these sort of files?
I suggest using the Rails tmp directory for this purpose. Then:
File.exist?("#{Rails.root}/tmp/deployment_enabled")
Phusion Passenger use this kind of mechanism too.
https://www.phusionpassenger.com/library/walkthroughs/basics/ruby/reloading_code.html#tmp-always_restart-txt
I recommend that you follow the Twelve-Factor App guidelines and keep your code separate from your configuration. In this case you are really talking about a simple boolean value, and the presence of the file is just the mechanism you use to define the value. This should be done instead through an environment variable.
Something like:
DEPLOYMENT_ENABLED=1 RAILS_ENV=production rails server
You would then use an initializer in Rails to detect the value:
# config/initializers/deployment.rb
foo if ENV['DEPLOYMENT_ENABLED']
The value can still be modified at runtime, e.g., ENV['DEPLOYMENT_ENABLED'] = 0.
I am using namespacing in my Rails 5 app to try to keep resources organised.
I've been generating resources using the command line by adding the namespace folder to the generate command.
This makes a folder in the models folder for the main folder which the namespaced files are saved in.
I've since been reading posts from others that suggest namespacing models is not a good idea.
An example of what I currently have is:
class Stance::Assessment < ApplicationRecord
It seems to work alright so far.
What is the problem with namespacing models?
If it is a problem, does that mean I can't organise my models into folder groups, or does it mean that the model class doesnt need to be named wiht the "Stance::"?
There is a certain cost of complexity involved with "namespacing" your models. Ruby does not actually have true namespaces. Rather it has has modules which provide encapsulation.
Rails and ActiveRecord was designed around placing your application code in the Main object (the global object). While this might seem like a bad practice it is very simple and works well with the convention over configuration approach. It also allows a much simpler autoloading scheme and avoids the need to nest every single file in an additional folder.
Namespacing does have great organizational merits though and lets you avoid collisions. But there are a few minor aches in the backside:
table prefixes, having the generated table names like my_app_projects_tasks is really inconvenient when you need to write a custom join.
You need to override ActiveModel::Naming so that it does not look for paths like my_app_projects_tasks_path when using the polymorphic route helpers.
You need to explicitly set the class_name option when creating associations or override how ActiveRecord resolves constant names.
you can prefix your models, so instead of Stance::Assessment you would have StanceAssessment. not as clean as a namespace but it's pretty close to it
If i need to add (project specific) classes to my controler in rails, what is the correct way/place to put and "include" them/there .rb files? (quotes for: not the ruby keyword include)
I am new to rails, and did not find the correct way. LIB sounds like for more public libraries and - what I have learned - is not reloaded per default in dev mode.
sure, I could put all in controler.rb, but ...
the anser for me:
First: there are no rules, if you keep in mind (or learn like me) the rails rules:
NameOfCla -> name_of_cla(.rb) <-- not using class as word for clearence
name your class how you like:
class ExtendCon #<--- not using controller here for clearence
....
put it in a file extend_con.rb, wait for the path explaination, please. if you named your class 'MYGreatThing' it will be 'm_y_great_thing' (never testet that), so avoid chineese charachters
if your controller uses
#letssee=ExtendCon.new
rails learns that class and file (extend_con) on its own. i still did not figure out if a server restart is needed. (the first time)
choose the path to put the file: (I preferre Daves way) app/myexten or what you like, making it 'app' specific and still distquishes to standard rails 'things'
if you are not lasy like me (i put it in app/ontrollers)
put the path you have choosen into
config/application.rb like (comments are there to find it)
# Custom directories with classes and modules you want to be autoloadable.
# config.autoload_paths += %W(#{config.root}/app/controllers)
config.autoload_paths += %W(#{config.root}/app/myexten)
this one workes for me in all modes including "developer" and i did not need to put "my own" things in app/lib
It depends.
I tend to put library code used explicitly (e.g., instantiated, injected, etc. into app-level artifacts) into app/xxx where xxx signifies the "type" of thing, like decorators, services, etc.
Magic stuff tends to end up in lib, like monkey patches, architectural-level artifacts, and so on.
Code anywhere can be added to the autoload paths, required automatically by an initializer, etc.
Rails 4 comes with an internal directory for controllers called concerns. You could try using that.
app/controlls/concerns
If you have concerns/foo_bar.rb, you include it as follows:
class FooController < ApplicationController
include FooBar
end
Models also have their own concerns directory. I find this approach useful, and it can be applied to Rails 3. You just have to add the directories to your load paths.
I would like to define a constant (like the admin-email-adress) depending on the environment. What is the easiest way to do this?
I'd like something like that, in development.rb (or test or production.rb):
ADMIN_EMAIL = "foo#bar.com"
And be able to access it by calling something like
ADMIN_EMAIL
Is there an easy way or do I have to do something like creating a module and initialize it and stuff (and in case you're wondering if I have any idea about this, unfortunately: I don't)
It works this way, but one has to
restart the server, for the constants
to take effect.
In config/environments/, there are some configuration files that get executed based on what environment you're currently in. Try defining a constant in one of those.