I know they are adding a lot to the core of rails, but what about the
rest?
Will the Engines plugin live on to provide the missing pieces?
On 19 Feb 2009, at 19:05, Trevor Rowe wrote:
I know they are adding a lot to the core of rails, but what about
the rest? Will the Engines plugin live on to provide the missing
pieces?
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 W. 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.
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’.
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.
If for any reason migrations or assets don’t make it into core, I
think we’ll have to fulfil them via an ‘engines’ plugin for 2.3, but I
hope that won’t be necessary 
Apologies for not being more transparent with this - I hope it makes
sense.
Let me know what you think,
James
Engine-Users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
On 19.02.2009, at 22:58, James A. 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 W. 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.
On 20/02/2009, at 10:32 PM, Antonio Tapiador del Dujo wrote:
I know they are adding a lot to the core of rails, but what about
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.
BTW… I’ve already provided a simple patch to fix this issue, and it
doesn’t require another column or anything, it just changes the order
of the name and migration number.
“1-myplugin”.to_i == 1 <== problem
“myplugin-1”.to_i == nil <== ignored by standard rails.
Kind regards,
Samuel
On 20/02/2009, at 11:27 PM, Sven F. wrote:
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.
This might not work completely when some plugins are gems which are
likely read-only.
Kind regards,
Samuel
Thank you James, it would be really impressive if all this functionality
could
be included in the core.
Just a missing point, what about translations?
Cheers.
On 20 Feb 2009, at 10:39, Space Ship T.
<[email protected]
wrote:
it doesn’t require another column or anything, it just changes the
order of the name and migration number.“1-myplugin”.to_i == 1 <== problem
“myplugin-1”.to_i == nil <== ignored by standard rails.
While this works now, it is a hack which relies on Rails behaviour
that is not intentional.
Adding a column is a more elegant and robust hack, and the more
elegant the solution, the easier it will be to convince core to
integrate it, and this become a hack no more.
James
I’ve got several plugins in use across different applications I
maintain that depend on Engines. (Thanks, James, I’m glad your work
is now recognized in core.) Now that I’m migrating some of them to
2.3, I did find that I needed the migrations support and asset loading
support to a certain degree. So I whipped up a plugin that handles
these just two pieces of functionality. It’s on github, so fork away
and hack on it as you wish: GitHub - henrypoydar/engines-helper: A Rails 2.3+ plugin that provides database migrations and asset support for 'engine' type plugins
On 20/02/2009, at 11:58 PM, James A. wrote:
While this works now, it is a hack which relies on Rails behaviour
that is not intentional.Adding a column is a more elegant and robust hack, and the more
elegant the solution, the easier it will be to convince core to
integrate it, and this become a hack no more.
I can’t argue with that statement.
Rails plugins & migrations generally seem pretty hacked up.
Basically there are two characteristics of migrations:
- They have some sort of order.
- But, some migrations can be applied in parallel - i.e. they don’t
depend on some other migration. (i.e. most add_table migrations can be
run in any order)
Rails has introduced a lot of semantics that don’t actually appear to
make much sense or even are that useful:
Being able to migrate plugins backwards is almost completely useless -
I’ve never used it. 50% of the code in migrations for me is a waste of
time (it should just be generated automatically if required). In many
cases migrating backwards is impossible anyway without data loss or
corruption.
Timestamped plugins is a complete mistake in my opinion. They
overcomplicate the issue. Why not just allow plugins with the same
order number. Generally, this suits the purpose required anyway i.e.
003_add_table_a.rb
003_add_table_b.rb
Wasn’t the goal of timestamped migrations to allow multiple developers
to create migrations that don’t clash? Is it the purpose of the
“number” to be unique id, or provide order? In my mind, it makes far
more sense for migrations to be ordered rather than indexed.
In the above situation, we can apply “003” migrations in any sequence
- “A” followed by “B” or “B” followed by “A”. In the case they were
developed by separate developers, they can’t possibly rely on each
other anyway…
In the database, you’d have a migration table that listed the full
name of the migration:
Migrations:
^ name ^
| 003_add_table_a |
| 003_add_table_b |
The way to apply new migrations is just to list all migrations in
sorted order, then only apply them if they are not already in the
migrations db.
Generally, I think for plugins, migrations can be simply copied across
to the main migrations directory, and everything will work as expected
with this kind of design. The current migrations code is completely
over engineered and for 99% of users does not provide a significant
benefit, and makes things that should be natural, more complex and non-
intuitive.
A lot of code could be reduced by simplifying migrations in this way.
Kind regards,
Samuel
On 20 Feb 2009, at 09:32, Antonio Tapiador del Dujo wrote:
Thank you James, it would be really impressive if all this
functionality could
be included in the core.Just a missing point, what about translations?
Good point. I shouldn’t think this would be too hard.
James