I'm splitting a large Sinatra file into different files using registers. This is one way to have a modular Sinatra app using extensions.
I'm ending up with something like the following code:
MyApp < Sinatra::Base
register OneRegister
register SecondRegister
end
module OneRegister
def self.registered(app)
app.helpers OneRegisterHelper
app.get "/one-endpoint" do
do_stuff
end
end
module OneRegisterHelper
def do_stuff
# Some code
end
end
end
module SecondRegister
def self.registered(app)
app.helpers SecondRegisterHelper
app.get "/second-endpoint" do
do_stuff
end
end
module SecondRegisterHelper
def do_stuff
# Different code
end
end
end
The problem is how Sinatra works with registers and helpers. Every time I create a new helper for a register I'm polluting the main Sinatra app scope with the methods in the helpers.
So, the method do_stuff is going to be overwritten by the SecondRegisterHelper (this is how Ruby works when including a module) but I'd like to have different implementations for the methods without worry if I'm using the same method name or a different one (image an app with 25 registers with small methods in each one).
Basically, I'd like to have different registers with private methods because I usually write very small private methods with a single responsibility. Any ideas, how I can achieve this?
I don't think this is achievable in the way you are trying. If you have methods with similar names in different modules mixed into a single class the last just wins.
So in this case I would create a modular app combined with a config.ru to setup your application.
class OneRegister < Sinatra::Base
# helpers here
end
class SecondRegister < Sinatra::Base
# helpers here
end
In config.ru
app = Rack::URLMap.new(
'/one-endpoint' => OneRegister,
'/second-endpoint' => TwoRegister
)
run app
No you helpers are scoped to a single class.
Related
I know that in Cucumber that I can create a module and then include that module into the World object and all the methods that I have created within the newly created module are available globally
module MyModule
def my_method
end
end
World(MyModule)
Now anywhere in my cucumber tests I can call my_method and it will work
The issue I see here and an issue I have come across is duplication of method names, as the application gets bigger or other testers/developers work on the application.
So if I was to wrap everything up in its own module and create module methods like so
module MyModule
def self.my_method
page.find('#element')
end
end
World(MyModule)
MyModule.my_method
# This will return undefined variable or method 'page' for MyModule module
So being new to using modules I have read that you can extend other modules so that you can use those methods within another module
So to access the page method I would need to access Capybara::DSL
module MyModule
extend Capybara::DSL
def self.my_method
page.find('#element')
end
end
World(MyModule)
MyModule.my_method now works, but my question is rather than extend individual namespaces for every module that I need access to is there a way to extend/include everything or is this a bad practice?
Another example of where things fail are when I try to access instances of a class
module SiteCss
def login_page
Login.new
end
end
class Login < SitePrism::Page
element :username, "#username"
end
module MyModule
extend Capybara::DSL
def self.my_method
page.find('#element')
login_page.username.set('username')
end
end
World(MyModule)
So with this example if I was it try and call login_page.username I would get
undefined method `login_page`
I'm really looking for the correct way to be doing this.
In conclusion I am trying to understand how to use custom modules and classes in cucumber without having to load everything into the World object.
Yes, it's not pretty to extend a module multiple times, if that's really what you want to do, I can suggest a way you can improve it a bit:
base class which will inherit your page object framework and extend(include is probably the correct option here):
module Pages
class BasePage < SitePrism::Page
extend Capybara::DSL
end
end
Now your login class:
module Pages
class Login < BasePage
element :username, "#username"
def yourmethod
page.find('#element')
username.set('username')
end
end
end
Now the bits you are probably interested in, expose yourmethod to cucumber world:
module SiteCss
def page_object
#page_object ||= Pages::Login.new
end
end
World(SiteCss)
Now you should have access to yourmethod in a cleaner way...
Usage:
#page_object.yourmethod
Although the most important suggestion I could give you is run from SitePrism... Create your own page object framework... don't fall into SitePrism trap...
What's the correct way to call the erb function (which is available via Sinatra) if I have a helper class outside the Sinatra main application.
For example, I have in my_app.rb:
require 'sinatra'
require 'my_external_class.rb'
get '/' do
MyExternalClass.some_function(request)
end
Then I have a file called: my_external_class.rb
class MyExternalClass
def self.some_function request
erb :some_template
end
end
When running Sinatra and executing a get request, I get a undefined method `erb' for MyExternalClass. I assume I am missing either some require, or maybe I need to pass the Sinatra object to the class (but I don't know how to achieve that).
How could I achieve something like that?
You can achieve this by creating a helpers module for your methods:
# module instead of a class
module MyHelpersModule
# no need for 'self'
def some_function(request)
erb :some_template
end
end
Then in your main app file call helpers MyHelpersModule. This will make all the methods in MyHelpersModule available in your application and also, since they are executed in the same context, the existing Sinatra methods (like erb) will be available to your helpers.
require 'sinatra'
require './my_helpers_module'
helpers MyHelpersModule
get '/' do
some_function(request)
end
To imitate rendering behavior of Sinatra controller in some other class you can create module like this:
module ErbRender
include Sinatra::Templates
include Sinatra::Helpers
include Sinatra::ContentFor
def settings
#settings ||= begin
settings = Sinatra::Application.settings
settings.root = "#{ROOT}/app"
settings
end
end
def template_cache
#template_cache ||= Tilt::Cache.new
end
end
Here you may need to tune settings.root
Usage example:
class ArticleIndexingPostBody
include ErbRender
def get_body
erb :'amp/articles/show', layout: :'amp/layout'
end
end
This will properly render templates with layouts including content_for
I've defined a Sinatra helper in the usual way:
module Sinatra
module FooHelper
# code goes here
end
end
In my helper, among other things, I'd like to add a method to Numeric:
module Sinatra
module FooHelper
class ::Numeric
def my_new_method
end
end
end
end
However, in the interests of being unobtrusive, I only want to do add this method if my Sinatra helper is actually included in an application; if nobody runs helpers Sinatra::FooHelper, I don't want to affect anything (which seems like a reasonable thing to expect of a Sinatra extension).
Is there any hook that's fired when my helper is included, that would enable me to add my method only once that happens?
You can use the Module#included method to do this. I think you will need to modify your class definition slightly to use class_eval. I've tested the following and it works as expected:
module Sinatra
module FooHelper
def self.included(mod)
::Numeric.class_eval do
def my_new_method
return "whatever"
end
end
end
end
end
Probably something quite basic but I want to be able to use some custom helper methods in a modular Sinatra app. I have the following in ./helpers/aws_helper.rb
helpers do
def aws_asset( path )
File.join settings.asset_host, path
end
end
and then in my view i want to be able to use this method like so
<%= image_tag(aws_asset('/assets/images/wd.png')) %>
but i get the above area, so within my app.rb file i am
require './helpers/aws_helper'
class Profile < Sinatra::Base
get '/' do
erb :index
end
end
So is my issue that i am requiring it outside of my Profile class. which doesn't make sense as I am requiring my config files for ENV variables the same way and they are being read, but then again they are not methods so i guess that does make sense.
I think maybe im struggling to get my head around what a modular app is as opposed to using a classic styled sinatra app.
Any pointers appreciated
Error message
NoMethodError at / undefined method `aws_asset' for #<Profile:0x007f1e6c4905c0> file: index.erb location: block in singletonclass line: 8
When you use helpers do ... in the top level like this you are adding the methods as helpers to Sinatra::Application and not your Profile class. If you are using the Sinatra modular style exclusively make sure you only ever use require 'sinatra/base', and not require sinatra, this will prevent you from mixing up the two styles like this.
In this case you should probably create a module for your helpers instead of using helpers do ..., and then add that module with the helpers method in your Profile class.
In helpers/aws_helper.rb:
module MyHelpers # choose a better name of course
def aws_asset( path )
File.join settings.asset_host, path
end
end
In app.rb:
class Profile < Sinatra::Base
helpers MyHelpers # include your helpers here
get '/' do
erb :index
end
end
I have an util method into a Sinatra application and I would like to tested from my TestCase.
The problem is that I don't know how to invoke it, if I just use app.util_method I have the error NameError: undefined local variable or method 'util_method' for #<Sinatra::ExtendedRack:0x007fc0c43305b8>
my_app.rb:
class MyApp < Sinatra::Base
# [...] routes methods
# utils methods
def util_method
return "hi"
end
end
my_app_test.rb:
require "my_app.rb"
require "test/unit"
require "rack/test"
class MyAppTest < Test::Unit::TestCase
include Rack::Test::Methods
def app
MyApp.new
end
# [...] routes methods tests
def test_util_method
assert_equal( "hi", app.util_method )
end
end
Sinatra aliases the new method to new! before redefining it, so the simplest solution is to use that instead:
def app
MyApp.new!
end
Of course I only noticed that after I’d come up with the following, which I’ll leave in as it could be useful/informative.
A possible way to get round Sinatra redefining the new method and returning a complete Rack app a get hold of an instance your actual base class is to do what the “real” new method does yourself:
def app
a = MyApp.allocate
a.send :initialize
a
end
This is a bit of a hack, but it might be useful for testing.
Another technique would be to “walk” the middleware stack until you got to your class. The following is a little fragile, as it depends on all the middleware involved to use the name #app to refer to the next app in the stack, but this is fairly common.
def app
a = MyApp.new
while a.class != MyApp
a = a.instance_variable_get(:#app)
end
a
end
That won’t work on the yet to be released Sinatra 1.4 though (at least not on the current master, which is commit 41840746e866e8e8e9a0eaafc53d8b9fe6615b12), as new now returns a Wrapper class and the loop never ends. In this case you can grab the base class directly from the #instance variable:
def app
MyApp.new.instance_variable_get :#instance
end
(note this last technique may well change before the final 1.4 release).
The problem you are encountering is, that MyApp.new does not return an instance of MyApp but an instance of the middleware wrapping your App (usually Rack::Head or Sinatra::ShowExceptions). A good explanation can be found in the thread Sinatra Usage Question / Rack App.
The only solution I can think of is to change your instance method to a class method which can be called without the instance itself. As the instance of your App may be freshly instantiated for every request, an instance method probably doesn't have much advantages over a class method in your scenario.
Edit:
In the upcoming Sinatra 1.4 the initialization will change. Sinatra::Base.new will return a Sinatra::Wrapper instance, which exposes #settings and #helpers. This may help solve the problem of accessing Sinatra::Base instance methods. See the Sinatra Changelog for more information.