Rforum engine

Here’s a question for those well-versed in rforum or engines – or
both, ideally :slight_smile: 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.

  1. 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 A. wrote:

Here’s a question for those well-versed in rforum or engines – or
both, ideally :slight_smile: 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.

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.

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.

Kevin O. 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.

Ezra Z. 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.

On Dec 22, 2005, at 7:52 PM, Kevin O. wrote:

used for models, table names etc.
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 Z.
WebMaster
Yakima Herald-Republic Newspaper
[email protected]
509-577-7732

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 A. 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.

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:
Thoughts about engines and modules - Rails - Ruby-Forum
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? I had a look at
$EDGERAILS/activesupport/lib/active_support/dependencies.rb, which
looks to be quite aware of modules.

cheers
Gerret

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 S.

Gerret A. wrote:

I posted some thoughts about how to solve the problem of clashes between
rails apps a few weeks ago:
Thoughts about engines and modules - Rails - Ruby-Forum
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.