I'm currently constructing a Rails site to edit a collection of files used for configuration of various services. The files are simple plain text files. The point of the site is to provide an easy interface for editing the files as well as validate changes for the less technically incline individuals who will be editing them.
I've looked around but I can't seem to find anything on using text files instead of a database. What I do find suggests that what I'm trying to do may not be correct for rails at all. The closest thing have is this question, but the answers are less than helpful.
Is there a correct way to create an MVC for text files and not use a database at all?
Yes. Rails provides MVC with activerecord being default for models. you can keep rails views and controllers (VC part) and write your own models (M part). Imagine using mongoid ORM instead of active record. For that reason rails provides activemodel to make it easy for people to write their own models that are backed by different storage mechanism. look at https://github.com/rails/rails/tree/master/activemodel to get started on writing your own ORM that will use text files as backend instead of SQL database. Also include http://api.rubyonrails.org/classes/ActiveModel/Lint/Tests.html in your model test files to verify that your models conform activemodel api. After that, you can use rails form helpers in views and routes with your models without problem.
Related
When talking about Ruby on Rails API versioning, it's common to create a division in the controller level. They create new routes with new controllers in different modules, such as API::V2::ProductsController and so on.
The problem is: not all the code is in the controllers. Even a simple Ruby on Rails application has its code shared between models, views (which in this case would be the serializers) and controllers. Not to mention jobs, mailers and application specific libraries (lib/ directory) code.
Even if you version the controller with new controllers with different routes, the model would be the same for every version, and so would be the views and the database schema itself.
I know ActiveModelSerializer, one of the most used serializing gems, does implement versioning, but still, Rails models don't support versioning by default.
Is there a way to really version a Ruby on Rails API?
I would say that your view layer: your serializers or .rabl or .jbuilder files should contain as much presentation logic as possible (ideally all!). Thus: how this data is displayed to the user: a pretty formatted string, a JSON document with a certain structure, a JSON document with a slightly different structure.
If you have a User model, and you want to format the date a user joined the site, don't implement a User#dateUserJoinedISOStr method, but instead in the serializer get the date field and do the transformation to the proper iso string there.
Then you can switch on the API version requested, or use a completely different serializer if the changes between the two API versions are just too different.
Theoretically maybe you even think of the two api versions as different representations of the same resource, and use / abuse Rails content type format tools to pick the right content template.
This of course gets harder if you have a site that returns HTML as well as JSON (or, to put it a better way, "HTML representations in addition to JSON representations"). In that case I'd either use some clever route magic such that the version comes through the params OR buck convention a little bit and don't put a version number in your URL path (instead use a header!). Regardless, if your routes always go to the same place, then either have some if statements in the controller (to select the correct version serializer) OR a bunch of if statements in the serializer ("display that now, or not?").
I am new to ruby on rails and I am working on a web application written by ruby on rails. It has more than 10 models and I need to add some new attributes to some of the models as well as new methods and views. I also will need to remove or enhance some of the functionality. I know that I would need to generate new migrations and from there add/remove new columns. Then in controllers, add/modify methods, and update the views.
I wanted to know what would be the best steps (and in which order) for doing the above tasks. Also, do I need to change other files in folders like test or any other folder? What things should I consider to minimize the troubles later?
Thanks in Advance.
Since you are new to rails, the first thing you should do is to read through the getting started guide. This will help you understand the fundamentals of the rails framework and the application you inherited. After that, there are several other guides worth reading (from the same site) that may be directly applicable to the work you are doing.
Another incredibly helpful resource is railscasts. Some of these are outdated, but they are still a great starting place and can help introduce you to both new, powerful gems and rails techniques to get the work done faster and better.
As to your specific question, rails is built on an MVC architecture (meaning Model Views Controllers). It is in your best interest to try and follow this practice whenever possible. Reading up on this will clarify some of your questions as well.
When you run a migration, you will be modifying your database. The changes are viewable in the database schema (which should never be modified by hand, always modify it through migrations). This will add attributes to your models whose table you modified. In the controllers, you will add logic to deal with all of these things and the views will present the data to your users (or allow users to enter data). Asking which order is best is probably rather opinion based, but I would say you should modify the tables (run needed migrations) first. This way you can then generate the logic to deal with the new attributes. I would then create the controller logic and finally the views.
You also ask what other files need to be changed. This is heavily dependent on your system. At a base level, you should definitely be writing tests to support the logic you are generating (and many developers will advocate that you should do this before you write the other logic, a process called Test Driven Development).
TL;DR: Read the guides, work through a basic tutorial, and watch some Railscasts. This should get you up to speed on the process and best practices that go along with rails development.
I'm new to Ruby and I come from a C# background so apologies if this is very basic. I'm navigating around a large Rails project and looking at the model (ActiveRecord) classes. I want to be able to easily see all of the fields of a class so that I can see whether a particular class has the fields that I need. I can't find any way of doing this in the RubyMine IDE. Is there any easy way or am I misunderstanding the way that dynamic languages work? The only way that I have found so far is by looking at the underlying database tables.
TIA
You can look at schema.rb under the db folder.
I'm looking for the "rails" design pattern for code that fetches data from other websites.
I have a rails controller in my app that fetches data not from the database, but from external API's or scraped from the web.
Where's the "rails" place to put this code.
For quick implementation, I just stuck it in a model, but the model doesn't interact with the database - or support standard model functionality - so that feels wrong, but my understanding of rails and ruby isn't yet solid enough to know where it should go.
The way the code works roughly is
controller calls model.fetchData args
the model uses HTTParty or similar to make the call
processes data
passes it back to the controller
Any advice?
Broadly-speaking I think there are two possible ways to do this:
Create a plain ruby class to contain the methods for making requests to the API(s) and processing responses from it(them). You can include the HTTParty module in this class with include HTTParty. The usual place to put this code is in lib/ (make sure that wherever you put it, the path is in autoload_paths).
If you're doing anything really complex, or the API itself is complex, you might want to consider creating a separate gem to handle interaction with the API(s). The term for this type of gem is an "API wrapper" -- if you look around, you'll see there are lots of them out there for popular services (Twitter, LinkedIn, Flickr, etc.)
Notice I haven't mentioned activerecord. If you're not going to be saving anything to the DB, I don't see any need to even create any activerecord models. You can get by with just controllers and views, and then (if needed) pick and choose components from activemodel (validations, internationalization, etc.) to make your ruby API wrapper class feel more like a Rails model. For example, one thing that I've done in an app I'm working on is to apply validations to query strings before actually making requests to an external API, which is a bit like running validations on database queries before querying a DB. See this article by Yehuda Katz for more on how to make plain ruby objects feel like activerecord models.
Hope that helps. I answered another question very similar to this one just yesterday, you might want to have a look at that answer as well: Using rails to consume web services/apis
I'm just starting out in Rails and there's a lot I still need to learn so I'm likely to be on Stackoverflow more often than normal asking beginner Rails / Ruby questions.
I'm just trying to figure out how Helpers work in Rails. From what I've seen so far, Helpers are intended to be used with Views and not so much with your Controllers.
However I would like to make a simple function that will validate the user input given in params (check if certain params are defined and optionally check if their value is valid).
Can anyone explain to me what would be the best way of implementing this? (Keeping in mind that I will want to use this in many different controllers so it should be globally available.)
I also noticed that by default Rails does not generate a lib folder in the main application folder. Are developers to place their libs outside the app folder in the main folder, or does Rails use libraries differently?
With regards to your validation issue, it depends on what you are validating.
If the data makes up objects from your problem domain, also known as models, then you should use the built in validators from ActiveModel. This is probably what you should do, but its hard to say without knowing the exact problem. See the Rails Guides on Validations. You can tell if this is the case by asking yourself if the data that needs validation will be stored after you get it. If so, its most definitely a model. An example of this kind of data would be the title and text fields of a blog post being sent to Rails from a browser form.
If the data is something tertiary to your models, or specific to presentation, then you should be fine using helpers. You noticed that helpers are used mostly in the views, and although this is true, theres nothing stopping you from using them in the controllers, you just have to declare that you will use them using the ActiveController#helper method. Inside the ApplicationController class, a lot of devs will put helper :all to just include all the helpers in all the controllers. Once the code has been required once, it doesn't really incur that big a performance hit.
Do note that almost all incoming data can be modeled using a model. A big school of thought in the Rails world subscribes to the Fat Model idea. People say that putting as much code as possible in the model and as little in the controller as possible separates concerns properly and leads to more maintainable code. This suggests that even if you don't think the incoming data is modelable (in the sense that you can create a model to represent it), you should try to make it a model and encapsulate the logic around validating it. However, you may find that making a helper function is faster, and either will work.
Your notion of validating user input is a good one. I get the feeling that as you are new to Rails you are used to doing these things yourself, but that doesn't quite apply here. In the Rails world, a lot of the common stuff like validations is handled by the framework. You don't have to check for presence in the params array, instead you call validates_presence_of on the model and let Rails spit the error out to the user. It makes things easier in the long run if you let the framework do what it is designed to.
With regards to your question about the lib folder, it doesn't really matter. You can put miscellaneous support files and libraries in the lib folder in the root directory and they will be available for use in your application (the files in the app folder). You can also choose to abstract your code into a plugin or a gem and include it that way, which a lot of people opt to do. My suggestion for this would be to read up on the notion of gems and plugins before diving in.
Want you want is probably a custom validator (in Rails3):
http://railscasts.com/episodes/211-validations-in-rails-3
You can either add libs in a lib folder you create, or add them to config/initializers in a file you add. Files in the initializers directory are automatically loaded by Rails.