Loading...

engine-developers@lists.rails-engines.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [Engine-Developers] Exploration of possible refactorings for Rails 2.0 Sven Fuchs Fri Dec 21 12:03:58 2007

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 Brown:

> 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

--
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