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
on 2006-01-13 19:14
on 2006-01-14 01:25
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.
on 2006-01-14 03:58
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.
on 2006-01-14 04:11
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/tra... - james
on 2006-01-14 11:19
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