It seems like DHH has never built almost the same site twice as he
won’t embrace the idea of engines into Rails. What changes need to be
made to Rails API so engines don’t need to monkeypatch their way in?
Is there a way that patches could be phrased so they look appealing to
the Rails Core team in other ways and thus be applied? One thing I’m
particularly interested in engine/plugin loading order but from
reading on the engines site it looks like that is now a feature in
Rails core. Is there any movement on trying to make defining models in
an engine a little smoother?
Plugin load order will feature in 1.2, which makes things a lot easier
(politically, at least) for people who want to use the engines plugin;
more about that later. As for the other features… it’s tricky. It’s
often far simpler to monkey patch a feature in, than it would be to
provide a complete ‘proper’ patch that Rails could adopt. Other
aspects, such as the ‘code mixing’, are fairly magical, and not
suitable for core at all, imho.
A lot of the work in the engines plugin is providing a better
infrastructure in which plugins can operate - creating object
instances to represent plugins, and so on. Some of these might be 2.0
candidate features; we’ll see what David’s plans are for that as time
goes on.
As for defining models in plugins - what do you feel is the main
difficulty?
As for defining models in plugins - what do you feel is the main difficulty?
Perhaps it has changed but when i was using Engines many months ago, I
had to define the contents of the model in a module and then mix that
module into the model. Sorry if that is worded so clunky but hopeful
you know what I’m talking about. It isn’t that it is really difficult
it just doesn’t seem as smooth or friendly as being able to define the
model exactly how it would be defined in a plain vanilla Rails app.
You can certainly define a model as you would in a Rails application -
the only reason for moving functionality into a module is to make it
possible to override selected methods within the application. There
may be better ways to achieve this now (for instance, putting your
plugin models into a module).
Plugin load order will feature in 1.2, which makes things a lot easier
(politically, at least) for people who want to use the engines plugin;
more about that later. As for the other features… it’s tricky. It’s
often far simpler to monkey patch a feature in, than it would be to
provide a complete ‘proper’ patch that Rails could adopt. Other
aspects, such as the ‘code mixing’, are fairly magical, and not
suitable for core at all, imho.
Maybe the magic could still happen outside of Rails but the Rails api
would be defined in such a way that the magic wouldn’t be hitting a
moving target with each Rails release? The only reason I ask is that I
am sure that it is a lot of work over time for you to keep readjusting
the monkey patching. Also I imagine that there are developers that
wouldn’t use engines because they know it is monkey patching and might
break in the future “and what if James A. looses interest in
engines!?!?!?!” To a certain degree this makes me a little nervous. I
don’t need any professional consoling about it but it would certainly
be great if engines keep moving in the direction of somewhat more
officially supported.
A lot of the work in the engines plugin is providing a better
infrastructure in which plugins can operate - creating object
instances to represent plugins, and so on. Some of these might be 2.0
candidate features; we’ll see what David’s plans are for that as time
goes on.
Perhaps any tickets for changes shouldn’t have your name attached?
I am joking of course but the politics do seem a sensitive.
Has any direction for Rails 2.0 been stated other than removing
components and pagination? Is something big already planned?
As for defining models in plugins - what do you feel is the main difficulty?
Perhaps it has changed but when i was using Engines many months ago, I
had to define the contents of the model in a module and then mix that
module into the model. Sorry if that is worded so clunky but hopeful
you know what I’m talking about. It isn’t that it is really difficult
it just doesn’t seem as smooth or friendly as being able to define the
model exactly how it would be defined in a plain vanilla Rails app.
Thanks again,
Peter
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
