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
On 28/11/2007, at 8:59 PM, Nathaniel Brown wrote:
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.
On 11/27/07, Sven Fuchs <[EMAIL PROTECTED]> wrote:
[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.
2. 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.
3. 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.
4. 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)
_______________________________________________
Engine-Developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
--
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
_______________________________________________
Engine-Developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
