I'm reading active_support documentation and it says that whenever there's a controller action called, rails searches for corresponding helper class. If there's no such class, an exception is thrown, caught and possibly rethrown.
I'm curious how (in)efficient is this and should I just have empty helper classes for the sake of not throwing exceptions in the background of my code?
I'm not trying to do any kind of premature optimization, I'm just looking into internals of rails and was curious as to why would they make it so that it always throws exception when there's no helper defined.
Here's the related documentation:
http://guides.rubyonrails.org/active_support_core_extensions.html#extensions-to-nameerror
Any insights and more details would be appreciated.
Thanks!
I'm going to answer from a place of "wishful thinking", not from any particular knowledge about Rails internal code. I know (and love) that Rails was built with the busy developer in mind: it was designed by someone who hates repeating himself, with an ethos of DRY code and sensible defaults in mind.
So given that, it sounds like a horrible idea to worry about setting up empty helper classes just for the sake of making the Rails startup code more efficient. That's very opposite to the intentions that Rails was built on, and I think you can count on the community holding to those intentions going forward.
Related
I've been looking at Administrate source code and would like to know if it's a good practice or not the use of a generic controller and what implications it would have, like code complexity, performance degradation, etc.
Sometime ago, there was a gem inherited_resources that provide this feature, but since Rails 3.0 or 3.1 has been said we no longer need them.
So, since I have some very simple models (with only two or three fields) I could create a generic view and controller to manipulate them and save a lot of lines of "duplicated" code. Although I'm afraid, by avoiding repetition I could be creating another monster.
I've been looking for a Rails way to do this, but failed, so I would thanks some advice.
Note: I'm not looking to implement or use an admin dashboard, but use in my application instead
All Rails admin-panel implementations will make you hurt when you will try to make something more complex than stupid simple CRUD-application. I recomend you not to use such solutions. I had experiece in usage three different Rails's admin-panels and all of them had bad design and a lot of limitations. They are hard to mantain and extend their functionality.
I was wondering, as testing a controller in rails run the associated views (even if not shown) and integrate many models concerns (by saving, updating,...), testing controller should be almost enough for all applications near enough of CRUD classical architecture. Am I wrong?
Furthermore, views can be tested in the browser, as eyes can be quicker to check than describing everything in a test (and they can achieve CSS control too.)
Thank you for your point of view!
PH
Testing only your controllers will tell you that, broadly, your app is working, at least in terms of not 500'ing or whatever. But can you be sure that it is doing the exactly correct thing? If all you need to test is standard resourceful behaviour like "given params[:id], is the record with id <params[:id]> loaded?" then just testing the controller might be enough.
But, you will inevitably add more complicated behaviour into your models. In this situation, your controller may set some variables or something, without raising an error, by calling a model method. At this stage, it's much cleaner to test the model method directly, to make sure that given a particular set of conditions, it does the right thing.
I am using Ruby on Rails 3.2.9 and Ruby 1.9.3-p125. After my previous question I ended up that I have an issue on metaprogramming a self-implemented acts_as_customizable plugin since the related code has side effects on other classes than that "acting as customizable".
To summarize the issue: the acts_as_customizable method stated for an Article model "internally" (through metaprogramming) adds a customize method to a Comment model and, in order to save time, Rails doesn't load all those classes on startup making the application to raise a NoMethodError - undefined method 'customize' for #<Comment:0x0...> until the Article class is loaded.
A proposed solution was to require_dependency 'article' in the Comment model, but I am looking for another way (maybe, better of the proposed one) to have the application to work as it is doing right now, but without any issue as-like that explained in this question. That is, I would like to keep a *short code** and the same behavior but using a more "appropriate" way to make things, maybe changing the loading process of classes or planning a big refactoring for the whole code, if necessary.
How should I handle this situation? What do you think about?
Update: After some study, I discovered that the problem arises only in development mode since the config.cache_classes is set to false making classes to be reloaded on every request.
Note: I want point out that metaprogramming is very usefull in my case and Article and Comment classes are highly related one to another in the aspect of my conception of "customization". So I would like to find a solution alleviating changes to the underling behavior.
* In my case, metaprogramming (even if it has side effects) makes me to avoid a lot of code statements.
I am developing a community / news article website where there is a side column with different "blocks" on nearly all pages. In these blocks is "Recent Articles (showing five most recent articles)," "Recent Blogs," "Recent Comments," you get the drift.
When I started out building the application, I wasn't real sure where to put the controller code (say, to call #recent_articles = Article.where...etc). I didn't think it could go into the Articles controller, because it's not always the Articles controller being called. So I thought it would work best in the application controller, as most content on the site would be calling this. I put "#recent_content" into the application controller, did a :before_filter to load it.
You might see the flaw in this. As I'm getting better with Rails, I went back to refactor as the site was loading horribly and sure enough, all my logic in the application controller defined by before_filter was being loaded on every action, no matter if it was needed or not. (The site sped up dramatically when I cleaned house on the application controller).
My mistake is realized, but I still need to define the instance variables for #recent_articles, #recent_blogs, etc somewhere, so they load up only when needed. Granted I'll be eventually caching the site content when it goes into production, but I want to be a good Rails programmer here.
So here is my question...exactly how would you handle this situation and where would you put the logic? I can think of two ways, not sure which one is better...
The first way...I took a look at a project from another Rails developer and I noticed he was doing odd things like this by creating files in the /lib folder. For example, defining a method for page meta tags or active menu states. I honestly haven't messed with the /lib folder before, figuring most of my stuff should stay in the /app folder.
The second way...seems to me like helpers might seem the way to go. Maybe I could define a "recent_articles" helper, call my #recent_articles instance variable in there, then render and pass the results to a view file in my shared folder.
Overall, which one of these ways is the better way to go, either from a performance or best-practices viewpoint? Or is there a better way of doing this that I'm unaware of?
Whenever there are many models that can call a particular method, i would probably use a module. I think that is what you are talking about in your first idea, since /lib is where modules are placed.
You can use helpers as well, but it's a good idea to keep logic out of helpers, only in models if possible. Helpers should be just used as a way to present data, they are part of views. If logic is added, then something is wrong :)
Make sure that you do not have logic in your controllers as well. I would be doing the same things in the beginning, but it's really a bad idea. Instead, put everything in your models, or maybe a module if they seem to be used by many other models.
Hope that helps you a bit :)
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.