On 19.02.2009, at 22:58, James Adam wrote:
It's my hope that we'll fold almost all of the significant features
of the engines plugin into Rails itself. Those features are
migrations and public asset copying.
Samuel Williams pointed out an issue with the current migration
strategy (see the Lighthouse for more info) that I'm keen to resolve
in whatever strategy Rails adopts. My current thinking is that the
schema_migrations table should have an extra column - 'source' -
that would solve this issue. David remains to be convinced, but I
hope to show that it relatively simple.
Hmm, I can't seem to find that Lighthouse ticket. What'd be wrong with
just copying all the migrations from plugins to the main migration
directory? With timestamped migrations that should just work or
shouldn't it?
Public asset copying shouldn't be very difficult to port. The slight
hurdle is whether or not to bring the engine asset helper extensions
across (i.e. adding the :plugin option to stylesheet_link_tag, etc),
or whether or not assets should be copied into the main folder
itself so the default helpers work. I'm tending towards the latter,
as it will be easier to convince 'core'.
They should be copied IMO. Although I also prefer a more explicit
approach here like just having a rake task that copies all the assets
up to public. Would also be nice to have a task for syncing assets
"back" to their respective plugin directories.
When the logic is placed in some accessible place (like
Rails::Plugin.copy_assets) it would be trivial to hook that up to
happen per request in dev mode, too.
The only feature that I am not planning on 'campaigning' for is the
code-mixing. This value this was originally intended to bring was to
seamlessly layer plugins on top of each other, but I'm no longer
convinced that this is a goal worth increasing the codebase of Rails
for. There are other, simpler ways to override single methods in a
Ruby class that I'd rather pursue.
Could you expand on this a little bit? :)
The use case I have is that people want to extend "engine" stuff from
their app/ directory. So when we ship a, e.g., UserHelper in a plugin
and they try to overwrite/extend that in app/helpers/user_helper the
original helper won't be loaded anymore. So they have to pick a
different name or move it to a namespace.
Another point I found missing is that Rails does not currently keep
track of its plugins. Of course it's trivial to add a custom
PluginLoader that takes care of that.
Maybe a future Engines plugin could rather provide a collection of
"missing" Engine features that people can explicitely opt into. Like
"ok, I want magic code mixing, but I'm happy with the migrations rake
task"
Anyway. Rails 2.3.0 still has a few bugs open regarding the Engines
implementation. But I'm already totally happy with this stuff now in
core. I really love that. :)
_______________________________________________
Engine-Users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
