Rails 3 autoload_paths versus Rails 2 load_paths - ruby-on-rails-3

So, I figured out that I needed to change my config.load_paths to config.autoload_paths but when I did that, I start seeing this exception:
Expected /path/to/myapp/app/helpers/controllers/my_helper.rb to define Controllers::MyHelper
In Rails 2, it never complained about the helpers/controllers folder, but now it seems that it expects a namespaced module. Do I have rename all of my helpers, or is there some other way this can work? I have so many helpers that I use helpers/models helpers/views and helpers/controllers to keep them all organized.
Thanks in advance!

Rails 3 does expect your classes to be namespaced according to file name and directory hierarchy, so you will have to rename your helper to Controllers::MyHelper.

File naming conventions in Rails 3 are a lot more strict than they were in Rails 2 for performance reasons. Rails 3 expects the file structure to directly match the class hierarchy.
If you would like the run the application in Rails 3 I would suggest removing the helpers directory or adding Controllers:: to the front of each class declaration.

Related

Eagerloading files in directories inside the app folder in Rails 3. How is it done?

I read this:
If you add a dir directly under app/
Do nothing. All files in this dir are eager loaded in production and
lazy loaded in development by default.
If you add a dir under app/something/
(e.g. app/models/concerns/, app/models/products/)
Ask: do I want to namespace modules and classes inside my new dir? For
example in app/models/products/ you would need to wrap your class in
module Products.
If the answer is yes, do nothing. It will just work.
If the answer is no, add config.autoload_paths += %W(
#{config.root}/app/models/products )
I want to know how Rails does this. How does it:
Load the file inside a folder (named folder_nest) in the app folder only if the contents of that file are wrapped in a module named after that folder (folder_nest module). How does this happen?
There must be some logic that says: "if the thing inside of app is a file, eager load it. If it's a folder, only load the contents of said folder if it's wrapped in a module named after said folder."
Anyone know where this logic is? How do I read Rails source code?
Also, is config/initializers eagerly loaded? Where is that logic?
Well, looks like you have a lot of questions best answered by the one question "How do I read Rails source code"
Personally, I do something like the following from the command-line:
subl `bundle show rails`
and then use the text editor (sublime in this case, textmate also works) + search, just read the code. Sometimes I'll insert "puts" statements in there to make sure I'm reading the right code and run it just to be sure.
You can answer most of your own questions about the initialization sequence, etc, that way.

remove new.haml/ new.erb from ruby on rails?

The default ruby on rails scaffolds generate a new.haml or new.erb these include only 1 line: = render 'form'
Thus, basically the file is obsolete, is there any preferred way to remove the new partial and make it use the _form partial instead straight away or would this go against rails conventions?
no, there is no preferred way. it goes against rails conventions.
TL;DR don't do it.
if you don't need any customizations on your templates and are just creating basic CRUD stuff, have a look at admin tools like RailsAdmin ActiveAdmin Typus etc.

ExtJS 3 Code Architecture : Best way to organize class files and load them dynamically

I'am modernizing a legacy web application, with its frontend based on ExtJS 3.x.
Currently, user interface depends on large file of several thousand lines, with too many nested anonymous functions, encapsulated in an global `Ext.onReady()̀ per file. It's ugly, unreadable and not maintenable.
To maintain code and modernize it, I want gradually refactorize it by :
using namespaces
exploding big files : one class per file (grid, store, form ...)
organizing class files in a good directory structure (app/module/grid|store|...)
loading dynamically class files, when required (maybe with Ext.Loader.load() ?)
optimizing loading by using minifier, as assetic, if possible (in a next step).
All these problematics seems natively solved in ExtJS 4, with its class Loader, its dependency system (require), its Application Singleton and its structure folder conventions...
In ExtJS 3, it seems more confused. So :
What are the best practices in extjs 3 to organize code "like" in extjs 4 ?
Do you have clear examples illustrating these problematics ?
Ext3 is an entirely different beast than 4. Code organization is really up to the developer. I personally would avoid dynamic loading in favor of minification of the entire app. This is what ext4 would give you in a production app. They really only intend dynamic loading for debugging purposes. I have gone the dynamic loading/module route before with Ext3 and it was a regret. It is OK with 4 with it built into the class system.
If you are using a later version of 3, do namespaces with Ext.define. It will do the Ext.ns for you internally and will make upgrading to 4 easier down the path.
You are correct that you shouldn't have big files or config objects, but don't go too overboard. Try to group things into logical classes. A grid can be part of class that contains other components that make sense as a view.
If you do want to upgrade to 4 later, I would recommend trying to emulate the structure a little at least with stores and views. 3 doesn't really impose any structure.
I would avoid dynamic loading with 3. See above.
Definitely minify. Not only will there be much less data going over the wire, but you get huge savings by removing all the overhead of a GET for each script. Gzip might help a little too.

How to name a coffeescript file for a Rails 3.1+ namespaced controller?

If I have a Rails 3.1+ controller called PeopleController and a second one for admin functions called Admin::PeopleController, how should I name and/or construct the associated coffeescript files to be picked up unambiguously when a given controller is hit?
It seems for the standard people controller, I should create people.js.coffee - that makes sense. How do I name the coffeescript file that will get loaded for the admin people controller? Is there a naming convention I can follow, or does the one coffeescript file need to be used for both?
Firstly, it doesn't really matter what you call them. If you're requiring the whole tree, or at least specifying the files you want to include, in your application.js file then they'll all get picked up anyways.
If you're including the files individually then you'd still need to specify, presumably in your layout file, which one(s) you're including with the usual stylesheet tag.
I guess the convention would be to name them people.js.coffee and admin_people.js.coffee.

how to override rails 3 engine models and controllers in the main application?

I want to be able to override models and controllers of my rails 3 engine in the base app.
Inspecting $LOAD_PATH, I found engine's 'app/{models,controllers}' there, but I can't explicitly require engine's model or controller file: require 'engine_name/model_name' fails with "no such file" (tried with both namespaced(app/controllers/enginename/*) and plain engine).
So, what's the best way to extend engine's models/controllers in rails 3 without copying them to base app?
Basically, it's a load order problem. So, if I explicitly require model from engine, everything's ok, but I hope there is a better way.
So I actually went back and wrote the documentation. The answer is to Open Class the Controller and Model classes using either,
Class#eval_class
ActiveSupport::Concern
More details here,
http://guides.rubyonrails.org/engines.html#overriding-models-and-controllers
(edited. Changed from "edgeguides" subdomain to "guides" subdomain)