I'm building a platform in Rails that will act as a basis for a few other Rails applications. Ideally I would like this to be a shared engine, on which the other concrete applications can build.
It would be nice if the applications could extend the base classes that the engine provides. AFAIK this can be done using monkey patching, but that feels 'hacky' to me.
I stumbled onto what looked like the solution, which was to just create 'mirror' classes in the main Rails app, which extend those of the engine:
# SharedEngine/models/shared_engine/post.rb
module SharedEngine
class Post < ActiveRecord::Base
def hello
"Hello"
end
end
end
# App/models/shared_engine/post.rb
require SharedEngine::Engine.root.join('app', 'models', 'shared_engine', 'post')
class Post < SharedEngine::Post
def hello
super + " world"
end
end
However, it looks like there are some autoloading problems. After server startup, it prints "Hello". Then after I save the app model, it says "Hello world".
The Rails engine guide suggests putting shared code into concerns. Is there any other way to get this working cleanly without having to create concerns for every class?
Since you need to create a basis for a few Rails apps to reduce boilerplate i suggest having a look a Rails Application Templates. Using templates you may provide all the necessary scaffolding without monkey-patching any class.
Related
The very first line written about sinatra is it is DSL for quickly creating web applications in Ruby with minimal effort. I can understand it is light weight, very flexible, quick for creating web apps and with minimal effort but not able to understand how it is a DSL?
One reason is that it defines actions ("verbs") within its domain as methods, for example:
get '/hi' do
"Hello World!"
end
Here Sinatra has incorporated an action from its domain--namely the HTTP request method "GET"--into its "vocabulary."
(Similar to building a library around banking and defining methods like account or customer.)
Is this more about the true definition of DSL?
I have created a simple class under the models folder like so:
class CaffeineShops
def initialize
end
end
When I run rails console and try CaffeineShops.new(), I get a message: "NoMethodError: undefined method 'new' for CaffeineShops::Module"
I am using Rails 4.1.
Any ideas why I am getting that error?
You cannot name a model the same name as the application itself. When you run rails g caffeine_shops this creates a module named CaffeineShops which will power your application.
The module is utilized in many files including
config\application.rb
config\environment.rb
config\environments\development.rb
config\environments\production.rb
config\environments\test.rb
config\initializers\secret_token.rb
config\initializers\session_store.rb
config\routes.rb
config.ru *actually starts the application on Rack-based servers
Rakefile *loads rake tasks for the application
When you then try to name a class the same name it creates ambiguity in the rails application so your code is assuming you mean the module CaffeineShops not the class CaffeineShops.
If you were to actually use a generator to define this model rails would make it very clear there was a problem with this e.g.
rails g caffeine_shops
cd caffeine_shops
rails g model caffeine_shops
#=>The name 'CaffeineShops' is either already used in your application or reserved
by Ruby on Rails. Please choose an alternative and run this generator again.
I'm using YARD to generate docs for a couple projects that I'm working on. In one, I'm co-developing a gem that hosts a lot of redundant and shared resources that will be used by other projects.
What'd I'd like is for references from the first project to classes or methods in the gem to show up in the docs for the main project. For example
Gem
class Widget
# Spins the widget of course.
def spin
end
end
Project
class SpecialWidget
# Jump and {#spin}.
def dance
end
end
I'd like the docs for SpecialWidget to generate an actual link to the Widget#spin method.
Can this be done?
How do I access the app instance so I can test the foobar() method?
class App < Sinatra::Base
get '/' do
return foobar
end
def foobar
"hello world"
end
end
This is a late reply, but I am trying to find a flexible way to do that too.
I found in Sinatra's source code (1.4.5) that creating an instance of the app with new! allows testing the app's methods directly. Exert from a test setup with Test::Unit and Shoulda.
class AppTest < Test::Unit::TestCase
setup do
#app = App.new! # here is the point.
end
should 'say hello to the world' do
assert_equal "hello world", #app.foobar # or #app.send(:foobar) for private methods.
end
end
There are consequences. Using new! does not create the usual Sinatra::Wrapper that becomes the entry point to the middleware pipeline and the app in normal settings. So the new! approach will work only if the tested methods are really "helpers" that do not rely on middleware functionalities (e.g. SSL).
Alternatively, a post on Rspec proposes an alternative solution. I used something similar in the past, but it requires more work that is not always the best choice. It had the advantage to offer broader coverage of code to test. The isolation of the app with new! sounds good though, if we are taking about "unit" testing.
Note on #three's comment: A non-trivial app should separate API methods (usually in the app) from all helpers, etc. Helpers ending up in a separate file are cleaner, easier to maintain, and easier to test. But I definitely understand cases where a first version of an app would include a few helpers, with awareness that refactoring will be necessary. And even then having tests brings in some more confidence in the software itself, and in the future refactoring as well.
It doesn't matter what you test - it is how :) => http://www.sinatrarb.com/testing.html
I have a rails app called X and a rails mountable engine called Y.
App X has Devise and engine Y has CanCan which works with the hosts apps devise installation. In order to seperate the concerns of host app and mountable engine, the engine has a CanCan ability model as well as the host app.
My problem is the following, as per CanCan documentation you can change the default ability model like so https://github.com/ryanb/cancan/wiki/Changing-Defaults.
My problem is that if I setup the of default ability class in the mountable engines application controller like so:
module Y
class ApplicationController < ActionController::Base
def current_ability
#current_ability = Ability.new(current_user)
end
end
end
I get the following error:
uninitialized constant Ability
(On a side note, when I edit the file and reload the page without restarting the server it works fine)
If however I put the same method into the host app's application controller:
class ApplicationController < ActionController::Base
def current_ability
#current_ability = Y::Ability.new(current_user)
end
end
Everything works as expected (which also means that Devise and CanCan are setup correctly).
Anyone got any ideas of why this is happening? I might not understand mountable engines correctly however I always thought that they are isolated from the host app, thus when accessing a page defined by the mountable engine the host app's application controller shouldn't even be executed.
it is most likely that your engines application controller is not loaded at all. Rails engines behave bad if you have same class name in the main app. here is the issue if you want to look at. I would recommend using the explicit declaration in your engine. Use Y::Ability instead of Ability.