Build a small part of an app, or a complete app itself, drop it in and you are good to go. Along with this, you can overwrite the functionality and views with out having to do anything fancy to your own code. Great!
The issues that need to be resolved have already brought up in this thread with the keys being using modules (which may be a set back if the core team doesn't support models in modules or someone writes a plugin for the support) and trying to avoid the black magic of classpath loading/searching and such.
Question, how does the current implementation find what controller to execute the action out of? Right now it looks like it looks through your app directory, then each engine directory for a controller that has the action in it. Correct? Then it does the same for the views, stopping at the first one it finds for the right action.
If this case why dont we do something like the following. Why doesn't each controller with the same module and class name get loaded, in whatever order they are started (and it does matter), and then just let ruby do the overriding and everything that it does by default. This kind of brings us back to the idea of plugins which override existing classes mostly to add functionality.
Pros to this method:
You dont really have 'search' the load path for your controllers, you'll load them all and be done with it.
Reduces the 'black magic' effect in that you know the last engine you start is going to have the final say in how it behaves and where its loaded from. (kind of where engines are not, but with a few issues)
Let Ruby do what Ruby does best and handle the dynamic nature of the language byitself.
We stick with the same methodolgies of overiding a particular controller/action as we have now.
Cons:
Could be slow in development mode. Each request would need to search through the engines and reload all the controllers related to each other.
--erm....all I can come up with now, but I'm sure there are more.
I think engines do this already, but I'm not 100% sure because of the weird behaviour we are seeing. The way views are handle seems to be pretty good right now and I don't know if anything really needs to be changed with those. It uses the first one it finds in the order that they were loaded. Pretty simple if you ask me.
Just some ideas anyways whether they'll work or not, I'm not sure :)
-Nick
On 1/18/06, James Adam <
[EMAIL PROTECTED]> wrote:
I get your gist Nick - when you can control the 'load order' of
engines dynamically, you can effectively control inheritance. If it's
made concrete via direct subclassing, you can't really 'insert' a
class in between a controllers superclass and its own implementation.
The 'solution' (see how I love my 'quote marks' today) might be to
impement the controller code as modules, whose order of inclusion
could then be controller either explicitly:
class MyUserController
include LoginEngine::UserControllerModule
include FreakyEngine::UserControllerModule
include UserEngine::UserControllerModule
...
end
or perhaps more cleverly by injecting in the engine startup:
Engines.start :login, :freaky, :user
(...and then somewhere in the bowels of each engine...)
UserController.include(ThisEngine::UserControllerModule)
The order of inclusion in this case would be determined by the order
each engine is started ( i.e. the order each init_engine.rb is
evaluated). The particular UserController would be determined by the
load path, and the LoginEngine would probably provide a stub to be
used in the case where the user didn't provide their own. The drawback
to this approach is that doing these kinds of dynamic injection tends
to fail in development mode - when everything is unloaded, the modules
aren't re-injected. But that's something we might be able to
explicitly handle too.
- james
On 1/18/06, Nick Stuart <[EMAIL PROTECTED]> wrote:
> 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
>
>
> On 1/17/06, James Adam < [EMAIL PROTECTED]> wrote:
> > 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
> > _______________________________________________
> > engine-developers mailing list
> > [email protected]
> > http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
> >
>
_______________________________________________ engine-developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
