Forum: Rails Engines development Thoughts about Engines 1.1, dependencies and code overloadin

Hey guys,

I'm toying with the idea of replacing the current code-overloading
scheme in Engines (where it merges code from multiple
controllers/helpers). What I might do instead is just have people use
normal inheritance/module inclusion. So if you wanted to change a
method in the UserController of the LoginEngine, for example, instead
of just creating your own /app/controllers/user_controller.rb with the
new method, you might actually create that controller as a subclass:

class UserController < LoginEngine::UserController
  def protect
    # your overloaded method
  end
end

The advantage of this is that it means I don't need to search load
paths or modify any require strings. It also makes it a bit clearer to
the application developer that their controller is part of a grander
piece of code (currently there's no explicit relationship between
overriding controllers and engine controllers).

An alternative scheme would be to have the controller code in a module
with a stub controller in the engine, which wouldn't be loaded if a
similar controller existed in the main app. This would be identical to
the way the user model object is defined and overridden currently.

Doing something like this may solve the current problem of having to
get REALLY freaky with loading/requiring code (see Ticket #53 for
instance) annd be more future-proof, but also might introduce new
issues.

Anyway - does anyone have any thoughts? The floor is open...

- james

I like the idea of avoiding as much "black magic" as possible. Which
to many, the dynamic runtime classpath/loading issues seem to be.

I'm just trying to think how you would find the all the overloaded
classes and make sure they are all used correctly. For example, the
login and user engines.

Right now the user engine would inherit from the login engine, fine,
but what if someone had an additional engine that modified the login
engine with additional methods (overriding existing methods would be
messy in any case), how would you know where to find the new
extensions to the login engine and not use the user engine controller
instead.

I don't know if I'm making any sense here, but I hope you get the gist 
of it.

I have some other thoughts, but am trying to find a way to formulate
the wording so it makes some sense :)

-Nick

Hi James,

I think this is a good idea because
1 - makes the code more readable
2 - avoids to create an heavy and dangerous legacy for future 
development of the engines concept
3 - does not really have a dark side (Not that I can see. Can anybody 
mention one?)

In general I think that the philosophy behind the engines should be to 
create pieces of really reusable SW more than go on the "black magic" 
path, as Nick points out. In this sense I would even suggest that we 
should get in the habit to __dedicate a namespace to our engines__.

If, for instance, I write a todo_list_engine, I probably want my 
contoller to be called TodoList::ItemController, otherwise whoever wants 
to use my engine has to make sure that there are no other ItemController 
in his/her application.

Would this make your work with the engines plugin more complicated? What 
is your opinion?

Rails at the moment is not really supporting (not easily at least) 
namespace usage on the model side. This is, in my opinion, the major 
problem to be faced for the estabilishment of a sound engine concept.

Mauro

James Adam wrote:
> I'm toying with the idea of replacing the current code-overloading
> scheme in Engines (where it merges code from multiple
> controllers/helpers). What I might do instead is just have people use
> normal inheritance/module inclusion. So if you wanted to change a
> method in the UserController of the LoginEngine, for example, instead
> of just creating your own /app/controllers/user_controller.rb with the
> new method, you might actually create that controller as a subclass:
> 
> class UserController < LoginEngine::UserController
>   def protect
>     # your overloaded method
>   end
> end

I am just getting started learning Ruby (I hardly know much at all--and 
that goes for Rails and the Engines, too), but as an old C++ guy, I 
remember with horror the problems we used to have when 'upgrading' to a 
new version of a C++ framework, where we inherit from the provided 
functionality of an older version of the framework.

Similarly, I don't know if a late-binding script language like Ruby has 
similar problems or if your current code-overloading scheme solves it or 
has the same problem, but if I were you, I'd google a few keywords like 
"framework class brittleness upgrade problems C++" etc., you get the 
idea.  Maybe even try Borland OWL or Microsoft's windowing framework for 
C++ (I can't recall the name of it now), then head over to the Ruby 
language forums to ask the gurus there about class design and 
"versioning over time" of Ruby classes and see what they say.

HTH,
Brad

Hello.

I would prefer the inclusion approach, as used for models currently. I 
don't see any reasons for using inheritance in this case.

Regarding per-engine namespaces, I had the same feeling too. But. First, 
nothing prevents from making a namespace manually, by moving your 
controllers into a subfolder. Second, in the cases like Login/User 
engine, it is not clear how these namespaces should be related. (Will 
UserEngine get it's own namespace, which would include everything 
contained in the LoginEngine namespace?)

This way, a careful study is required. However I agree that namespaces 
are very important for establishing wide usage of engines.