Table of contents
1.
Introduction
2.
Configuring Settings
3.
The setting, enabling and disabling
3.1.
Putting off evaluation
3.2.
Configuring multiple settings
4.
Built-in Settings
4.1.
The configuration and deployment environment, or :environment
4.2.
: sessions - cookie-based sessions enable/disable
4.3.
Log requests to STDERR with logging.
4.4.
Allows users to enable or disable the POST _method hack.
4.5.
: root - The root directory of the application,
4.6.
: static - Static File Routes Enable/Disable
4.7.
View the template directory at: views
4.8.
: run - turn on/off the in-built web server
4.9.
Raising mistakes permits exceptions to spread outside the application:raise_errors
4.10.
: lock - use a mutex lock to ensure single request concurrency.
4.11.
Show exceptions and turn on elegant error pages:show_exceptions.
5.
Frequently Asked Questions
5.1.
Should I ever take Sinatra?
5.2.
What makes Sinatra tick?
5.3.
Why should Sinatra always be chosen over Rails?
5.4.
Describe Ruby rack.
5.5.
Rails with Sinatra: what is it?
6.
Conclusion
Last Updated: Mar 27, 2024
Medium

Available Settings in Sinatra

Career growth poll
Do you think IIT Guwahati certified course can help you in your career?

Introduction

Sinatra is a Ruby-based domain-specific language and free and open source web application library. It is an alternative to Ruby on Rails, Merb, Nitro, Camping, and other Ruby web application frameworks. The Rack web server interface is required. Frank Sinatra, a musician, inspired its name.

Introduction

Blake Mizerany created and developed Sinatra, which is compact and adaptable. The standard model-view-controller pattern utilised by other frameworks, such as Ruby on Rails, is not followed by this one. Conversely, Sinatra concentrates on "quickly and simply building web applications in Ruby."

It is also referred to as a microframework due to its considerably smaller size when compared to Ruby on Rails.

Configuring Settings

Several built-in settings in Sinatra regulate whether particular functionalities are turned on. Application-level variables known as settings are accessible in the request context via the settings object and can be changed using one set, enable, or disable methods. In addition to the built-in default parameters offered by the framework, applications can set their unique settings.

Configuration Settings

The setting, enabling and disabling

The set method adds an attribute to the application using the setting name and value in its most basic form. The settings object: the framework allows access to settings from within requests.

set :foo, 'bar'
get '/foo' do
  "foo is set to " + settings.foo
end

Putting off evaluation

Every time a setting value that is a Proc is read, an evaluation is carried out so that other settings may be used to calculate the value:


set: foo, 'bar'
set: baz, Proc. new { "Hi " + foo }

get '/baz' do
  "baz is set to " + settings. baz
endy be used to calculate the value:

 

If the foo option is left alone, the /baz response should read "baz is set to Hi bar." is modified.lue:

Configuring multiple settings

A Hash can be passed to set to specify several settings.

The preceding illustration might now read:

set :foo => 'bar', :baz => Proc.new { "Hi " + foo }

 

Built-in Settings

setting

The configuration and deployment environment, or :environment

A symbol that designates the deployment environment; it is commonly set to either production, test, or development. When the APP ENV environment variable is not set, the environment defaults to the value of the environment variable (ENV['APP ENV']) or development.

A specific environment can be created:
 

set: environment, : production

: sessions - cookie-based sessions enable/disable


Sinatra comes with support for signed (but not encrypted), cookie-based sessions, but it is turned off by default. Give them access though.
set: sessions, true

 

The Rack::Session::Cookie component is added to the middleware pipeline of the application to implement sessions.

Sinatra ruby

Log requests to STDERR with logging.

When enabled, writes a single line in Apache common log format to STDERR. In traditional style apps, this setting is enabled by default; in Sinatra, it is deactivated by default. Underlying classes.

The component Rack::CommonLogger is used internally to produce log messages.

Allows users to enable or disable the POST _method hack.

Whether the HTTP POST _method parameter hack should be enabled is determined by a boolean value. When this is the case, the value of the _method argument contained in the POST body takes precedence over the actual HTTP request method. The _method hack is used to disguise POST requests as other request methods (such as PUT and DELETE) and is often only required in rudimentary contexts, such as HTML form submission, which do not support the entire spectrum of HTTP methods.

hacking

The Rack::MethodOverride component is added to the middleware pipeline to implement the POST _method hack.

: root - The root directory of the application,

The root directory from which the application was built.

The default assumption (: app file setting) is that this is the directory holding the main application file.

The settings for the default: public folder and: views are built using the root directory.

Setting the: root setting specifically, as seen below in the main application file, is a typical idiom.

set :root, File.dirname(_FILE_)

: static - Static File Routes Enable/Disable

enable disable

Whether static files should be provided from the application's public directory is determined by a boolean (see the: public folder setting).

When the value of when: static is true, Sinatra will first determine if a static file is present and serve it.

When the public directory is current, the: static setting is automatically enabled.

View the template directory at: views

a string indicating the location of the directory containing view templates.

The root directory of the application is presumed to have a directory with the name "views" by default (see the: root setting).

Using a delayed value that makes reference to the following is the most effective technique to specify a different directory name inside the application's root: ts root setting

set: views, Proc_name.new { File_name.join(root, "temp_lates") }

: run - turn on/off the in-built web server

Whether the built-in web server is launched after the app has finished loading is determined by a boolean value. When the: app file matches 0, this parameter is disabled by default. For instance, when launching Ruby myapp.rb directly from a Sinatra application file. To turn down the internal web server:

set : run, false

Raising mistakes permits exceptions to spread outside the application:raise_errors

permit exceptions

Boolean indicates whether or not routes and filter-based exceptions should bypass the application. When deactivated, exceptions are saved and assigned to error handlers, which commonly output a customized error page and set the status code 5xx. Raising exceptions outside of the application allows them to be handled by the server handler or Rack middleware like Rack::ShowExceptions or Rack::MailExceptions. This feature is enabled by the: raise errors parameter. 

: lock - use a mutex lock to ensure single request concurrency.

lock

Sinatra can be used in threaded environments, where several requests are handled concurrently.

But not all programs and libraries are thread-safe, which can lead to sporadic failures or overall weirdness.

All requests synchronize on a mutex lock when the: lock parameter is enabled, guaranteeing that only one bid is handled at once.

By default, the lock setting is deactivated.

Show exceptions and turn on elegant error pages:show_exceptions.

Enable error pages that display the backtrace and the environment in the event of an unhandled exception.

Environments for development are by default enabled.

Frequently Asked Questions

Should I ever take Sinatra?

A working web application may be created using just one file and the Sinatra programming language. Sinatra is a suitable starting point for new developers to learn Ruby web application development and can aid in preparing for more complex frameworks, such as Rails.

What makes Sinatra tick?

Sinatra makes use of a series of requests that are made to the web server and then answered. These inquiries are contained in a controller, a file inside your program that communicates with the internet.

Why should Sinatra always be chosen over Rails?

Sinatra performs fewer functions out of the box and is significantly more lightweight, resource-efficient, and demanding. Rails, on the other hand, is crammed with features and comes with a tonne of code, and if you know how to use it, it makes it very simple to construct complex web applications quickly.

Describe Ruby rack.

Ruby programmers created Rack, a modular interface between web servers and web applications. Application programming interfaces (APIs) for middleware and web frameworks are encapsulated in a single method call for HTTP requests and responses using Rack.

Ruby Webserver Interface is called Rack.

Rails with Sinatra: what is it?

Sinatra is a server-side HTTP library, whereas Rails is a framework for developing model-driven web applications. Sinatra is the best tool if you think in terms of HTTP requests and responses. Rails are the way to go if you require complete integration and as little boilerplate as possible.

Conclusion

This article has gone through Sinatra Settings. For example, if you want to learn more about frameworks, please click here. I suppose it is clear to you. Still, have doubt? Then please comment.

You may also check out our other article on Spring Boot.

If you find any problems, please comment. We will love to answer your questions.

Attempt our Online Mock Test Series on Coding Ninjas Studio now!

Ninja, have a great time learning.

thank you

Live masterclass