On Sun, 5 Mar 2006 14:51:17 -0500 David Corbin <[EMAIL PROTECTED]> wrote:
> Maybe I'm very wrong, but engines are not services. They are more than that, > because services don't generally have a UI. A service with a UI is, by definition, a service ;-) In the traditional variant of MVC (not web oriented) the couple Model+Ctrl offers a service. The View is observing the Model and showing aspects of its state. In principle delegation works very well with the MVC pattern: given 2 MVC, A and B you can in general expect that if Ctrl-A invokes CTRL-B, then both Model-A and Model-B get modified. The View-A and view-B will react accordingly (and independently). Try to imagine that B is the Login engine (changing the state of the logged-in variable) and A is somebody needing Login authorization and you'll see that the original idea is not absurd or incompatible with the Engines idea. > If you want to go create "J2EE for Ruby" (which is what it kind of sounds > like > have at it, but don't muck up engines in the process. What was originally proposed is so much less than "J2EE for Ruby"! Basically we are talking about a hash table holding references to the available engines that allows to use delegation instead of inheritance __when convenient__. As Manuel Holtgrewe was suggesting, we should just evaluate if the cost of saving some copy/past + small rewriting is worth the effort. Nathaniel Brown is going more in the "J2EE for Ruby" direction. This was not my original intention, but I can see good points in what he says. Of course a lot of discussion is necessary, but my first reaction is that if we have a well decoupled design, I think that the current Engines could easily and transparently run on top of Nathaniel's framework. - Mauro _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
