Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have spent alot of time developing on sinatra, and that has worked fine for me because I have only worked on small projects and scale has not been a problem. Now I have the need to use rails, and the structure is a little confusing to me. I understand that when I type localhost:3000/images rails looks for the route in routes.rb (e.g. get 'images#index'), then goes the the controller images then in images looks for a index function, and finally finds the index view and renders it.
Why are all of these changes necessary? Couldn't it be simpler like sinatra (which seems to just include the controller step in the main file)? In an answer I am looking for why it is better to do it the way rails does it including specific reasons, advantages and disadvantage with examples.
Thanks in advance!
Konstantin Haase is the current maintainer of Sinatra and feels that they both cater for different types of application:
They are both solving a different set of issues, even though they
indeed overlap. While Rails is a framework focused on writing model
driven web applications, Sinatra is a library for dealing with HTTP
from the server side. If you think in terms of HTTP
requests/responses, Sinatra is the ideal tool. If you need full
integration and as much boilerplate as possible, Rails is the way to
go.
David Heinemeier Hansson also believes that there was room for both of them, but feels that is size of your app that should influence which one to use:
Sinatra is great for the micro-style, Rails is not. As long as you
stay micro, Sinatra will beat Rails. If you go beyond micro, Rails
will beat Sinatra.
So, basically, Sinatra and Rails are different and they have different use cases. Rails is an open source full-stack web application framework. It follows the popular MVC framework (Model, View, Controller) model and is known for its "convention over configuration" approach to application development. So, as you can see controller is a part of Rails by design.
You can find many articles describing the differences between Rails and Sinatra and their use cases. Here are couple of interesting blogs:
Rails vs. Sinatra
Rails vs. Sinatra by Example
K M Rakibul Islam's answer is great. You might also check out Rack. Both Rails and Sinatra are built on it. Rack is a web server interface that expects an "app" to be a Ruby object that takes a request hash via a method called call and then to respond with an array that includes the http response code, the http headers and the response body. It's pretty barebones. Looking at Rack might give you a better sense of how the two diverge past that-- if you're interested in "how" rather than "why".
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm using yard to generate my documentation for Rails apps from an rdoc file. There are AngularJS documentation generators, but how could they be connected to generate one coherent document for an AngularJS + Rails app?
In this case it is probably fine to have them separated, and indeed may make more sense to have them separated. Angular is going to be solely for your client-side stuff, and I'm assuming you're then using Rails as an API or perhaps a different piece of the app's functionality. Either way, they are fundamentally doing different things, so it would make sense to have them in different doc sections.
You could create a "landing page" for your documentation if you'd like: one button links to Angular docs and one to Rails docs, and that would solve the need to have them both "in one place". Actually figuring out a way to make them overlap in the same system is likely not worth the effort though, and may actually be a worse user experience.
As the previous answer stated, it would be good to use two different tools and link them together.
I would start with something like Apipie or just rdoc to document the ruby stuff. Additionally I would search for a good js documentation generator. This article compares a four different generators, while 'Docco' seems to have a ruby port with that is called 'Rocco', that may be even able to generate documentations for both, ruby and js. JSDoc on the other hand enables you to integrate custom pages into your docs (here you could place a link to the apipie generator).
In general I would probably just go for the rails API doc and have some conventions for commenting your angular code, as the angular stuff probably has no API that is accessible by another part of your system and therefore only needs some internal documentation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I need to develop an interactive web app with an admin backend. I have thought about using Ember.js for the frontend and Ruby on Rails (with ActiveAdmin) for the backend.
But i have some questions:
1) Should i put the Ember.js app inside the rails project, or having both separate? Is there any performance difference or something i should know about choosing one of the two strategies? I like to have things as clear as i can.
2) Should i use Ember.js and Rails-API instead? I mean... i think i won't use almost anything about the Ruby on Rails project... But i am confused, as i need the Admin Backend...
I have some experience (a little) on Ruby on Rails, but as i am new to Ember.js, i would really appreciate any help you can give me.
I also worked on a similar kind of project, and believe me having two different projects will benefit you a lot.
I used followings:
Sinatra for backend
Backbone.js for frontend
It makes a lot easier to add the functionality in your code, when you use two separate apps.
I recently had a similar project with an Angular app and a Rails backend. I agree with Arslan. Having a Sinatra, Rack or other API is better than Rails.
Using Ember for some parts, and Rails for other parts (like the Admin section) is a bad idea because:
You are doing the same things 2 different ways: getting data, rendering pages, etc.
You would have 2 separate functionalities in within the Rails app: one Rails app and one API.
It is much simpler to run 2 separate apps than to put a Javascript MVC into a Rails app. You end up with complexity in getting the Asset Pipeline to do what you need.
Here's my take:
If you're fluent in Rails, stick with Rails.
Yes, Sinatra or other frameworks may be lighter, but you'd have to handle lots of things by yourself.
As for Rails-API, it's a good project, but it's a bit of hassle at the beginning to figure out what modules were removed, etc. You can make an API with Rails without Rails-API. You can always use Rails-API at a later point if it turns out you need the performance increase.
Use Ember CLI for your client application.
It's the golden path for developing ember applications and using third party libraries. The gem Ember-rails still works and is still maintained, but you should not start a new project with it.
Keep them separate
It simply makes more sense to have them separate. This way, development and deployments of both apps are not tied to each other.
It uses more repositories though, and if you're using github, it may mean you'd have to switch plans. But there are other options such as bitbucket where the pricing is not tied to the number of private repositories
I hope this helps you.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I see some old questions here and here
It is now 2014, and I also have a more specific question.
Another company has built a REST API. Now I want to build a web application that only needs controller and view. I was originally planning to build this with just PHP without the bloat of an MVC framework. Then I was thinking maybe doing it with ASP.NET with just simple code behind and .aspx approach (the non-MVC way). I was even considering using only JQuery and HTML. The reason I haven't really considered a full MVC framework is because I'm simply just sending data, getting data and printing data. I don't have to really implement business logic.
Right now I'm considering doing this in just the ruby language because it seems like such a clean and minimalist language. But is there any advantage to including the entire rails framework? If so, what features are worth considering in the rails framework for my purposes?
EDIT
It seems I got a close vote for opinion based. But I'm not looking for opinions. I'm looking for the advantages of rails framework for my purposes. In other words, what problems can the rails framework solve significantly faster than just using ruby+curl+print_line().
As example on how to answer the question objectively, you can state things like:
Scenario 1:
Rails makes CURL calls and displays in views like so.
Pure ruby make calls and outputs views like so.
Result: As can be seen, rails requires X fewer lines of code than pure ruby as it pertains to the OP's original question
Scenario 2:
Rails handles page caching like so.
Pure ruby page caching will need to be handled like so.
Result: As can be seen, rails require X fewer lines of code than pure ruby as it pertains to the OP's original question
By listing the problems the original rails authors hoped to achieve and solutions they hoped for us to utilize in the situation defined in the OP's original question, we can see quantitatively the advantages Rails has over pure ruby.
Rails is pretty big, and in my opinion you don't need the bloat of Rails for something this simple. Even though it's not an MVC framework, I would recommend something like Sinatra, especially since it doesn't force you to use a database at all. Sinatra is a very simple framework, and it's most useful when you just want a way to easily set up HTTP routing with basic view support. However, note that it is possible to create a model that doesn't use ActiveRecord with Rails.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm a studying CS and lately I've got myself really enjoying learning about web development..
Now, I have tried to learn AngularJS for a few times but then I wanted to focus more on backend first, since I already know the stuff like html/css/js which makes good part of frontend so wanted to see what backend feels like..
So I started learning Rails.. Now, since with my previous attempts of trying to learn AngularJS I learned that it is all about MVC, sending data from one to another etc.. My problem is, at first glance at least, Rails seems to work in the really similar fashion. The question is, why would anyone want to use both AngularJS and Rails at the same time, when, at least in the newbie's eyes -> Rails seems that it can handle both backend and frontend? Like, views are our frontend, and we can use css/js in those .html.erb files, wouldn't that be considered frontend after all?
Now, I'm almost positive there is a good answer to this since googling "why use angular with rails" usually comes with results of tutorials that explain to you how to integrate them, I just want some reasons so that I wouldn't be as confused as right now..
Thanks!
Rails is a server-side framework that produces HTML, JSON, and JavaScript as well as manages CSS and image assets.
AngularJS is a client-side framework. Generally, without a server component it really can't do much.
By default Rails doesn't have a client-side framework. You can use EmberJS, Angular, or others to make your client-side interface more responsive and flexible. Rails alone can't do this, it can't run in your browser.
Likewise, AngularJS can't run on your server. You need to combine them.
MVC at frontend is a recent development. Earlier days we used to develop everything at backend and use frontend only for animation, UI etc.,
Slowly with Ajax introduction we started doing more at frontend and less at backend.
Now we migrated completely to frontend. We use backend only for logics which should be decided at server side and database management.
Single line answer, we need rails or any backend only to serve few logics which SHOULD happen in the backend, User can change the logic if it is at client side. So we force them to happen in the server side. And ofcourse database should be at the backend.
Other than that , there is absolutely no need to use rails views and others.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm a compsci student who wants to get learn a little about web development -- I learn best by doing. I know basic html/css/php/javascript/xml, but since Ruby is one of my favourite scripting languages, I figured I'd learn Ruby on Rails.
I'd like to build a basic website for a friend's club at school that just provides information about their organization and services they offer, and have an admin panel on it that contains a very basic inventory system (item, number in inventory, cost -- that's it) in order to learn Ruby on Rails. I'll be hosting it on a computer on campus -- so I don't have to worry about hosting.
This might sound a little silly, but as someone who's never built a website themselves, I was wondering how exactly one goes about it with rails -- like, how do I make a basic layout for the main part of the site -- with things like "Home, About Us, Services, Contact, Club Executive" along the top? Do I have to make it in html and put it in the "view" section? The tutorials I've read on rails (Getting Started With Rails) actually make the basic inventory system seem easy, compared to this part, using a lot of the built in functionality of Rails and scaffolding. The Rails documentation is a tad bit confusing.
The "official" Rails book is quite good if you want to start building Rails applications. link
But actually is something like this:
Create the rails app using rails applicationname
Create the controllers. It seesm that for you one controller is actually enough, name it for example main: ruby script/generate controller main
Now you have a controller in app/controllers, called main_controller.rb. Here you can insert the actions you want this controller to respond. If you don't want the controller to do anything just show the view, then leave the method empty.
class Main < ActionPack::Controllers
def index
end
def about
end
def contact
end
(...)
end
Now you got a controller that will respond to index, about and contact.
Create the views for this controller in app/views/main/index.erb (and others, like about.erb)
You can simply use HTML if you want
Alternatively you can use a layout, that you have to define in app/views/layouts/main.rhtml In this layout use HTML, but wherewer you want to include the view, write <%= yield %>
Example:
<HTML>
<BODY>
<%= yield %>
</BODY>
</HTML>
You can include this layout in the controller by writing layout :main in the class (before the method declarations)
Now if you run ruby script/server in the root of the app you can access the pages you've created. They will be static of course, but this might get you going. You have to add models and some logic to your controllers to advance. I advice you to check the book I linked if you're interested in more, or check the alternatives of rails like merb (http://merbivore.org) which has some nice features and is usually faster, but lacks the maturity of rails.
I picked up the book "Agile Web Development with Rails", and it's excellent. It goes through building an online grocery cart.
You should read about Model-View-Controller architecture if you have not yet done so, as it is the basis for most web frameworks including Ruby on Rails.
It sounds to me like this site might not be the best way to learn Ruby on Rails.
Rails is really great for CRUD applications (applications which allow users to Create, Read, Update, and Delete records in a database). Since your site looks to be all static pages except for the "Contact Us" section (which I'm assuming is a form that sends an email with some kind of confirmation page), you're actually going to find yourself kind of fighting against "The Rails Way."
Ideally in a situation like this, you could just throw all of your static pages into the public/ directory and make a quick Rails scaffold for the "Contact Us" page.
But by doing that, you won't end up with a finished project that resembles a typical Ruby on Rails application, and in the worst case, you might find yourself having to "unlearn" or at least "relearn" a lot of the aspects of Rails programming.
I think building a CRUD application with several resources (the canonical "Rails blog in 15 minutes" is a great start. You'll learn more by practicing Rails conventions and seeing the kind of workflow and application that really allows Rails to shine.
Then when it comes time to build another mostly-static website, you'll know exactly what you'll need to do to go about it.
My 2 cents, anyway.
Start off with Mephisto. It will give a framework to achieve your goal rather fast... otherwise you may simply flounder learning the gazillion things involved in creating the rails website.
With a simple site, I'd go for a Ruby micro-framework. The three I like are: Sinatra, Ramaze or _why's 4k Camping (get the one with the bugs fixed). RoR would be overkill.
I must recommend Ramaze. If you already know Ruby, but don't know Rails yet, Ramaze is better suited to you because it is "closer to home" as far as Ramaze apps being pure(r) Ruby.
For your DB access, you get a choice of ORMs. Sequel is most popular among Ramazers, but there's also DataMapper and M4DBI.
As Alan Alavi already said: You should familiarize yourself with MVC, but that can be done simply by diving in and getting your hands dirty.