Here''s a question for those well-versed in rforum or engines -- or
both, ideally :) I''ve spent some time today turning RForum into an
engine, using rails 1.0, engines trunk, and rforum 0.1 (as rforum
trunk didn''t appear to work out of the box).
My rforum engine works, but only when I do two things that I found by
trial and error:
1) All rforum controllers subclass rforum''s ApplicationController. I
renamed it to RForumApplicationController, as the app using the
rforum-engine is likely to have its own ApplicationController. Now
when I try to use one of these controllers, it will work fine on the
first load after each server restart, but on subsequent pageloads I am
informed of "uninitialized constant RForumApplicationController.
This problem goes away when I put a load
''rforum_application.rb''
at the top of each controller. A ''require'' doesn''t do
the job. My
question: why? I brooded over $ENGINES/lib/dependencies_extensions.rb,
but couldnt see the answer.
2) In my app''s init_engine.rb I have to put
require ''common_model_behaviors'' # 1
require RAILS_ROOT + ''/config/app.rb'' # 2
When I leave out line 1, I get errors such as "uninitialized constant
ErrorRaising" (which is defined in
''common_model_behaviors''). But that
very same file is loaded inside the app.rb! So I''m confused why both
lines 1 and 2 are required, when line 2 seems to me it should be
sufficient.
I''ve been trying to figure this out for too long now. So as its 8pm in
Europe I''ll have a beer hope you guys can help me out!
As an aside, You may have noted (while shaking your head) that I
renamed ApplicationController to RForumApplicationController, and not
RForum::ApplicationController. I did try, but broke localization in
the process. Any reason why this shouldnt work?:
module RForum
class ApplicationController < ActiveRecord::Base
include RForum::Localization
end
end
cheers
Gerret
cheers,
Gerret
Gerret Apelt wrote:> Here''s a question for those well-versed in rforum or engines -- or > both, ideally :) I''ve spent some time today turning RForum into an > engine, using rails 1.0, engines trunk, and rforum 0.1 (as rforum > trunk didn''t appear to work out of the box).RForum trunk should work out of the box. 0.1 is REALLY old and not recommended.> My rforum engine works, but only when I do two things that I found by > trial and error: > > 1) All rforum controllers subclass rforum''s ApplicationController. I > renamed it to RForumApplicationController, as the app using the > rforum-engine is likely to have its own ApplicationController.That''s what confuses me about Engines. The Engines website says: "Rails Engines are a way of dropping in whole chunks of functionality into your existing application without affecting any of your existing code." Appearantly this is not true, if you have to check every class for whether it collides with any of the existing classes. Can anyone tell me what''s the point of using engines then? I''m not trying to flame, I''m really wondering. -- Posted via http://www.ruby-forum.com/.
> That''s what confuses me about Engines. The Engines website says: > "Rails Engines are a way of dropping in whole chunks of functionality > into your existing application without affecting any of your existing > code." > Appearantly this is not true, if you have to check every class for > whether it collides with any of the existing classes. Can anyone tell me > what''s the point of using engines then? I''m not trying to flame, I''m > really wondering.A well-designed engine subclasses the application controller. Obviously rforum isn''t a well designed engine yet, so there are bound to be problems. The only problem I have encountered along these lines is that the User and Login engines were written with singular names for the controllers (apparently the author doesn''t like/use the Rails inflector). This causes all sorts of headaches if you actually use the pluralization convention in your app. It''s not too hard to fix, but it can lead to some strange behavior. -- Posted via http://www.ruby-forum.com/.
Kevin Olbrich wrote:>> That''s what confuses me about Engines. The Engines website says: >> "Rails Engines are a way of dropping in whole chunks of functionality >> into your existing application without affecting any of your existing >> code." >> Appearantly this is not true, if you have to check every class for >> whether it collides with any of the existing classes. Can anyone tell me >> what''s the point of using engines then? I''m not trying to flame, I''m >> really wondering. > > A well-designed engine subclasses the application controller.How is this going to help? What happens if two engines have, for example, a "BookController" class?> The only problem I have encountered along these lines is that the User > and Login engines were written with singular names for the controllers > (apparently the author doesn''t like/use the Rails inflector).What do controllers have to do with the inflector? I thought it was only used for models, table names etc. -- Posted via http://www.ruby-forum.com/.
>> A well-designed engine subclasses the application controller. > > How is this going to help? What happens if two engines have, for > example, a "BookController" class?The engines are loaded in a specific order when they are started. The second one to load will overload methods in the first.> What do controllers have to do with the inflector? I thought it was only > used for models, table names etc.Normally if you generate a scaffold using the singular name of your model it will generate a plural name for the controller and look for the plural table name. In the case of the user_engine, if you generated a ''user'' model you would have a ''UsersController'' class for that model. The user_engine overloads the ''UserController'' class by default because the author didn''t use the normal rails naming conventions when he wrote it (I know...,it''s a matter of personal preference). Consequently, it doesn''t overload the correct class and it breaks. If you turn off the rails pluralizations before you generate your app, then you would be fine. Or you can do what I did and simply manually pluralize the names. This gets a little tricky because there are some links to singular controllers in the views that you have to hunt down. -- Posted via http://www.ruby-forum.com/.
On Dec 22, 2005, at 7:52 PM, Kevin Olbrich wrote:>>> A well-designed engine subclasses the application controller. >> >> How is this going to help? What happens if two engines have, for >> example, a "BookController" class? > > The engines are loaded in a specific order when they are started. The > second one to load will overload methods in the first. > >> What do controllers have to do with the inflector? I thought it >> was only >> used for models, table names etc. > > Normally if you generate a scaffold using the singular name of your > model it will generate a plural name for the controller and look > for the > plural table name. In the case of the user_engine, if you generated a > ''user'' model you would have a ''UsersController'' class for that model. > The user_engine overloads the ''UserController'' class by default > because > the author didn''t use the normal rails naming conventions when he > wrote > it (I know...,it''s a matter of personal preference). Consequently, it > doesn''t overload the correct class and it breaks. > > If you turn off the rails pluralizations before you generate your app, > then you would be fine. Or you can do what I did and simply manually > pluralize the names. This gets a little tricky because there are some > links to singular controllers in the views that you have to hunt down. >I personally use singular controller names and most of the open rails code I have seen does as well. Its an unfortunate bug in the scaffold generator that pluralizes the controller name if you specify it alone. # this will make a plural controller called GruntsController script/generate scaffold Grunt # whereas this will make a singular controller GruntController and model like you specified script/generate scaffold Grunt Grunt Singular or Plural its up to you but I mainly see singular and that is what I use. Cheers- -Ezra Zygmuntowicz WebMaster Yakima Herald-Republic Newspaper ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org 509-577-7732
Ezra Zygmuntowicz wrote:> Singular or Plural its up to you but I mainly see singular and that > is what I use.I guess you are correct on this... looking at the AWDR example, I see it also has singluar controller names. So apparently the problem was on my end and was caused by my over-reliance on the scaffolding generator. I''m sure I''m not the only n00b that this is going to nail. -- Posted via http://www.ruby-forum.com/.
> That''s what confuses me about Engines. The Engines website says: > "Rails Engines are a way of dropping in whole chunks of functionality > into your existing application without affecting any of your existing > code." > Appearantly this is not true, if you have to check every class for > whether it collides with any of the existing classes. Can anyone tell me > what''s the point of using engines then? I''m not trying to flame, I''m > really wondering.The Engines plugin is more like a Swiss army knife than a magic wand... I think what you''ve seen with RForum here is the similar to the issue that hit Duane as he was trying to extract Typo into an engine - while it''s often possible to go from standalone running application to engine with little work, you might have to move some code around to get a set off files that is suitable for dropping in beside other controllers. There''s one stand-out reason for this: neither Typo, nor RForum were designed to run within another Rails application[1]. When you''re writing a Rails application you are free to (rightfully) presume that you have complete control over environment.rb, application_controller.rb, and other common files. When you''re writing an engine, you don''t have this freedom, so you have to use other techniques to configure relevant parts of the app, and share code amongst all controllers. The "point" of engines is to make it possible for people to create well-designed, modular application ''slices'' that can be used concurrently. But that doesn''t mean that you can just plug these things together 100% of the time and expect them to work. That would be like choosing a random gearbox, random chassis and random engine, and expecting them all to ''just work'' when you bolted them together. Instead, you''ve got to use your skills as a developer to make sure that what you''re putting into your application is compatible with the rest of it. You''re essentially accepting some external code into your project - you owe it to yourself to really inspect what its doing, know how it works, and (in the case of controller names) the assumptions that it is going to place on the rest of your project. Engine creators (myself included) can definitely make things a lot easier on their end users . For instance, making sure that all your controllers are in a module, and using a set of named routes throughout your code would help reduce the likelihood that controllers might clash. So to get back to the original point. It''s normally preferable that you create an engine from scratch, since you will know from the ground up that you can''t expect to have full control over the rest of the application. However, if you''re taking an existing application and turning it into an engine, you must expect that you''ll have to re-engineer it slightly such that it doesn''t depend on application_controller.rb, etc. My suggestion would be to put as much code as possible in modules and worst-case ask users to include those modules in their application_controller.rb. But you might be fine with just including that module in each of your RForum controllers. james [1] controversial idea: there''s no reason why an application can be designed as a single engine within a ''scaffold'' rails application from the outset, since from a users'' point of view it would run just the same...
James Adam wrote:> My suggestion would be to put as much code as possible in modules and > worst-case ask users to include those modules in their > application_controller.rb. But you might be fine with just including > that module in each of your RForum controllers.So using modules for controllers would eliminate the problem of controller class name clashes? That would be great. I thought Rails would not yet play well with modules. But how would the routes work? There doesn''t seem to be a :module/:engine parameter for map.connect. And what about models? Can I have two different User classes, as long as they''re in different modules? I posted some thoughts about how to solve the problem of clashes between rails apps a few weeks ago: http://www.ruby-forum.com/topic/19040 Unfortunately I have received no feedback. -- Posted via http://www.ruby-forum.com/.
I''ve summarized my enginification of RForum at http://typo.gerretonrails.com/articles/2005/12/24/rforum-engine Not in the spirit of "this is what you should do and how", more of a "caution: this is what happens when you try".> So using modules for controllers would eliminate the problem of > controller class name clashes? That would be great. I thought Rails > would not yet play well with modules.I don''t think it does. Renaming RForum''s ApplicationController to RforumApplicationController worked fine, while repackaging as Rforum::AppliationController did not.> And what about models? Can I have two different User classes, as long as > they''re in different modules?I tried that, and found the answer to be ''no'' on edgerails.> I posted some thoughts about how to solve the problem of clashes between > rails apps a few weeks ago: > http://www.ruby-forum.com/topic/19040extract: "There might be problems I haven''t thought of, and changing Rails to deal with modules would probably be a lot of work. But on the other hand it could be a more general solution for both components and engines in the current form." Looking at your proposed solutions, they would address almost all of the issues I describe in my RForum/Engine report. In fact they would probably go a long way towards rendering James'' "controversial idea" less controversial (albeit not uncontroversial enough, judging by the engines debate that went/goes on). Have you identified some of the particular portions of the rails source (next to routing.rb) that need modification for making your proposed enhacements work? I had a look at $EDGERAILS/activesupport/lib/active_support/dependencies.rb, which looks to be quite aware of modules. cheers Gerret
Gerret Apelt wrote:>> I posted some thoughts about how to solve the problem of clashes between >> rails apps a few weeks ago: >> http://www.ruby-forum.com/topic/19040 > extract: "There might be problems I haven''t thought of, and changing > Rails to deal > with modules would probably be a lot of work. But on the other hand it > could be a more general solution for both components and engines in the > current form." > > Looking at your proposed solutions, they would address almost all of > the issues I describe in my RForum/Engine report. In fact they would > probably go a long way towards rendering James'' "controversial idea" > less controversial (albeit not uncontroversial enough, judging by the > engines debate that went/goes on). > > Have you identified some of the particular portions of the rails > source (next to routing.rb) that need modification for making your > proposed enhacements work?No, not yet. Unfortunately at the moment I don''t have the time to take a closer look at it. -- Posted via http://www.ruby-forum.com/.
Following up on this thread... I am interested to know if any work has progressed at releasing RForum as an engine? I am really interested in deploying RForum as a drop-in message board solution to a project I am developing, and was wondering if there were any official plans to release RForum as an engine in the near future? Thanks for any information anyone can provide. D. Taylor Singletary On 12/31/05, Andreas S. <f@andreas-s.net> wrote:> > Gerret Apelt wrote: > >> I posted some thoughts about how to solve the problem of clashes > between > >> rails apps a few weeks ago: > >> http://www.ruby-forum.com/topic/19040 > > extract: "There might be problems I haven''t thought of, and changing > > Rails to deal > > with modules would probably be a lot of work. But on the other hand it > > could be a more general solution for both components and engines in the > > current form." > > > > Looking at your proposed solutions, they would address almost all of > > the issues I describe in my RForum/Engine report. In fact they would > > probably go a long way towards rendering James'' "controversial idea" > > less controversial (albeit not uncontroversial enough, judging by the > > engines debate that went/goes on). > > > > Have you identified some of the particular portions of the rails > > source (next to routing.rb) that need modification for making your > > proposed enhacements work? > > No, not yet. Unfortunately at the moment I don''t have the time to take a > closer look at it. > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060127/e82d9fcb/attachment.html