Abstract: It seems that the AnyModule::AnyModel shadows AnyModel.
If you are in a hurry, please skip to “The Problem”.
The idea
One important topic in architecting engines is to make them as isolated
as possible in terms of namespace and database schema (if supported).
In this way we can be confident that our engine can be used by other
applications without risk of name clashes.
Example
As an example, let’s assume that we want to create a ‘task_list_engine’.
Ideally we would like to have a TaskList namespace and, for the
databases that support it, a separate task_list schema.
Given that we want to represent the concept of Category in our task
list, we will have a TaskList::Category model, a
askList::CategoryController and a task_list.categories table in our
database (task_list = schema name, categories = table name).
The Problem
Easy to check:
1 - create a test rails application (e.g. tasklist)
2 - setup a db (e.g. tasklist_dev) with a table (e.g. categories)
3 - from RAILS_ROOT
$ ./script generate scaffold category
4 - run the application and
point to http://localhost:3000/categories
you should see the usual good stuff.
5 - $ ./script generate model task_list/category
Now tha application is broken and you get:
“uninitialized constant Category” error.
It seems that the Task_List::Category shadows Category.
Can anybody explain why? Is it a Rails flaw?
Mauro
I can’t explain why, but I can confirm that rails, models, and modules
dont
seem to get along. I tried orginzing a project of mine like that and got
very weird problems popping up, that you’ve probably seen as well. I
think
this would be a good thing to pester the rails core team about. I can’t
imagine they would say seperating out your models into seperate modules
would be a bad idea.
-Nick
p.s. Using controllers in different modules hasn’t been problem. Have
done
that quite a bit with no surprising results.
Nick S. wrote:
I can’t explain why, but I can confirm that rails, models, and modules
dont
seem to get along. I tried orginzing a project of mine like that and got
very weird problems popping up, that you’ve probably seen as well. I
think
this would be a good thing to pester the rails core team about.
Definetely. There were a few mails on this topic on the rails-core
mailing list, but unfortunately no response from the core team.
Hi James,
I guess that what you suggest is the most sensible way to go about it.
My original intention (The Idea 
) was to improve the engines plugin
so that it could handle the modularization. What I mean: given the
ENGINE_NAME the engine generator creates all the models, controllers and
views with their own ENGINE_NAME subdirectories - mapped to the
ENGINE_NAME:: namespace.
For databases like postgres you could go even further: the model
ENGINE_NAME::MODEL_NAME < ActiveRecord::Base gets mapped to the table
ENGINE_NAME.MODEL_NAMEs
I agree to all the following (1a is my add on):
1 - Each part gets loaded into its own namespace.
1a- Clever Database mapping
2 - Demonstrate to community.
3 - Pray for adoption.
4 - Well, I don’t drink… Virtual beer for me!
I’ll have a look to the bug over the weekend.
Mauro
Super-secret idea: rewrite the Rails plugin system (and any other
parts of Rails dependency-mechanisms required) so that it handles
namespaces in a consistent, predicable, controllable and safe way.
Incorporate some form of ‘engine-style’ features into that system.
Make /app an implicit ‘engine’ at the top of the pile for elegance of
implementation. Each part gets loaded into its own namespace.
Demonstrate to community. Pray for adoption. Have a beer.
I have some ideas how to do this, but nothing is clear yet. First
though, if you guys could help me track down this bug…
https://opensvn.csie.org/traccgi/rails_engines/trac.cgi/ticket/53