Exploration of possible refactorings for Rails 2.0

Rails Engines Development
1

[sending this to engine-developers, please advise me if this is for
some reason not correct]

Hi John,

to get a better overview how things are interrelated in the current
implementation I’ve gone through a first coarse refactoring towards
the Rails 2.0 plugin architecture.

I’ve checked my results in here so everybody can have a look at it:
http://svn.artweb-design.de/engines/dev/vendor/plugins/engines

Of course that’s not meant as a serious proposal (there are not even
any working tests) but as an exploration of the existing code and the
overall direction of possible refactorings.

Like you said the Engines implementation can be slimmed down greatly
because Rails now ships with some important features itself.

Please criticise any changes I’ve made to overall structure.

Also, some questions arose:

  1. Tests

How do you think about specifying Engines’ behaviour in RSpec? Having
an executable spec story would probably make it easier for developers
to figure out what Engines actually does. As I have to go through all
the tests next, I could easily take notes accordingly and transform
them to an RSpec story.

  1. Backwards compatibility

There are some notes/flags about legacy support and deprecated config
support. Do you feel these should be continued to supported? Or should
Engines for Rails 2.0 remove the previously deprecated features?

Also there’s at least one feature that could be implemented more
cleanly by changing the api:

Previously the plugin’s init.rb was evaluated in the scope of the
initializer (I guess) while it is now evaluated in the scope of the
plugin instance itself. This allows to directly access the plugin
attributes from within the init.rb file.

That means that both of these could at least be deprectated:

Engines.current.version = ‘1.0’
Rails.plugins[:name] = ‘1.0’

… in favor of just:

version = ‘1.0’

When you look at
http://svn.artweb-design.de/engines/dev/vendor/plugins/engines/lib/engines/plugin/loader.rb
I’ve added some notes about how the loader could be implemented
really lightweigt if both of the usages above would not be deprecated
but entirely removed from Engines.

How do you think about that?

To help users with the migration there could be a simple generator
script that just replaces these occurences in the plugins init.rb
files if there are any at all. This would allow to have an even
lighter Engines implementation.

That said, this of course could also just be deprecated in Engines for
Rails 2.0 and removed in the next following release quite quickly.

  1. Question about routing / plugins

In the routing extensions there’s this comment:

Engines::RailsExtensions::Routing#from_plugin

At the point in which routing is loaded, we cannot guarantee that all

plugins are in Rails.plugins, so instead we need to use

find_plugin_path

Just to be sure about this. Is this still the case? From what
Rails::Initializer#process says, at this point (when routing is
loaded), all the plugins should be loaded.

  1. Question about an engine’s views behaviour

Is my understanding correct that Engines views do not overwrite
according
views in the application?

–
sven fuchs [email protected]
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)

2

My primary hope for 2.0 support is that we can get it to work without
having
to be so reliant on Engines to upgrade in order to get support in future
versions of Rails. I’ve just realized how poor this dependency has
become on
the delay in ability to upgrade my projects as I rely on Engines to
first
upgrade.

So with that said, I want to see what we can do to gear this upgrade to
independence on the Rails tree. How can we make it so that Engines are
drafted in such a way that they no longer “require” a specific Rails
version, and if they are on some core mods such as Plugin loading, that
it
is done in a manner that doesn’t rely, or relies on it as less as
possible
on Rails itself being compliant.

Food for thought. I haven’t considered this until now, so I’d like to
discuss. Engines should be in Rails core, but if we simply can’t get the
Core team to agree to getting a sub-app (engine) as a default plugin’s
functionality, we need to be self sufficient in our own support for
Rails.

James, would be to chat about this on IM if you have a few min. Wouldn’t
mind hearing what your thoughts on this are in detail. Maybe we could
setup
a chat on campire and all discuss it??

If there’s any support for this sort of approach, let’s queue it up.

3

I think this is a good idea. Whether it is possible or not, is another
question… because I’ll just go over to my crystal ball, and checkout
what features will be in the next version… ah!!..

In reality, I think that Engines will always be playing catch-up. But,
if interfaces can be designed to minimise the impact of changes within
Rails, that is definitely a worthy goal. The problem is, to minimise
the scope of the interfaces between Engines and Rails is to minimise
the scope of Engines themselves. Engines replicates key functionality
of Rails - its always going to be bound to the Rails way of doing
things, and that will change from version to version…

For example, the new naming scheme for views… does that work
correctly with Engines?

At the end of the day, if everyone can work on Engines and provide
patches for the latest version of Rails, that is a pretty good
solution. Deployment apps shouldn’t be built on the latest and
greatest technology without a good deal of caution, so this shouldn’t
really be a huge problem.

Regards,
Samuel

4

Am 28.11.2007 um 09:07 schrieb Space Ship T.:

way of doing things, and that will change from version to version…

For example, the new naming scheme for views… does that work
correctly with Engines?

Yes, I think it does.

Engines only adds some crawling through additional directories looking
for a certain file.

mods such as Plugin loading, that it is done in a manner that
Wouldn’t mind hearing what your thoughts on this are in detail.
Hi John,
overall direction of possible refactorings.
How do you think about specifying Engines’ behaviour in RSpec? Having
should
That means that both of these could at least be deprectated:
really lightweigt if both of the usages above would not be deprecated
for

plugins are in Rails.plugins, so instead we need to use

according

artweb design http://www.artweb-design.de

[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org

–
sven fuchs [email protected]
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)

5

As far as I am concerned it’s the approach that ties us to Rails so
dependantly. If we adjust the focus a bit, having a clear goal that is
to be
abstraction and a thin layer of dependence, I don’t believe this
shouldn’t
be a problem.

Like I said, I’d like to chat it up and figure out how we should make it
happen.

If Engines depend solely on themselves for underlying functionality,
then
this would be an end of the line scenario. From what I have experience
so
far working with them, Engines provide a middle layer for Rails.

6

Just to be sure to understand what you mean by “reliant on Engines to
upgrade”.

Do you mean that a specific engine (like Macaque) that’s written for
“Rails Engines for Rails 1.2” should continue to work on “Rails
Engines for Rails 2.0”? If that’s the case this is what I meant by
“backwards compatibility”. I.e. not hard to do from what I’ve seen.
But it’s the usual tradeoff with backwards compatibility and
supporting legacy stuff. The library is more heavyweight (which seems
to be a “marketing issue” with Rails Engines) and users might get
confused about all the options.

Or do you mean that Rails Engines itself should be agnostic about the
Rails version it is installed on at all? That might be a quite huge
target to hunt for.

Am 28.11.2007 um 08:59 schrieb Nathaniel B.:

Plugin loading, that it is done in a manner that doesn’t rely, or
Maybe we could setup a chat on campire and all discuss it??

an executable spec story would probably make it easier for developers

Engines.current.version = ‘1.0’

Just to be sure about this. Is this still the case? From what

Nathaniel Steven Henry Brown
604-724-6624 _______________________________________________
Engine-Developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org

–
sven fuchs [email protected]
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)

7

On 11/28/07, Nathaniel B. [email protected] wrote:

James, would be to chat about this on IM if you have a few min. Wouldn’t
mind hearing what your thoughts on this are in detail. Maybe we could setup
a chat on campire and all discuss it??

I’ll be in the #engines channel on freenode for the next couple of
hours.

8

On Nov 28, 2007 9:40 AM, Nathaniel B. [email protected] wrote:

If Engines depend solely on themselves for underlying functionality, then
this would be an end of the line scenario. From what I have experience so
far working with them, Engines provide a middle layer for Rails.

I’m also not clear what you’re referring to here. Do you mean that
plugins developed against the engines plugin are too tied to rails? Or
that the engines plugin itself relies too much on the specifics of
certain Rails’ internals?