It appears that in Rails''s initializer.rb, the $LOAD_PATH is initialized with the paths for all the components included in the app before the models. This has the effect that if there is Foo class in your models directory and a Foo class in a component you''ve included, the Rails loader loads the component and not the model from your models directory. While you could namespace the component to avoid conflicts, it seems like a valid strategy for customizing your component would be to redefine portions of the model from the component in an entry in your models directory. However, since the Rails $LOAD_PATH results in the models directory entry not being read, this seems impossible. Am I overlooking something/overlooking a better strategy to achieve this functionality? Is there a particular reason for this ordering I''m overlooking? Thanks, Fred -- Posted via http://www.ruby-forum.com/.
I doubt that the ordering of the load paths in this particular case is anything beyond an artefact of the order various parts of the Rails framework are initialized, and as such it shouldn''t be a problem to switch them around. Your best bet is to simply alter the $LOAD_PATH directly yourself, such that the component paths are pushed after the application ones; this shouldn''t be too hard to do, and could be shared between each of your applications via a plugin (or just a single method in a file somewhere). That said, it still wouldn''t be possible to redefine only portions of the Foo class - Ruby will only load the first one it sees (either from the application, or the component), and will completely ignore the other. The overloading features that the engines plugin provides might possibly help you, in some cases. - james On 7/20/06, Fred Wulff <fwulff@mobileevolution.com> wrote:> It appears that in Rails''s initializer.rb, the $LOAD_PATH is initialized > with the paths for all the components included in the app before the > models. This has the effect that if there is Foo class in your models > directory and a Foo class in a component you''ve included, the Rails > loader loads the component and not the model from your models directory. > > While you could namespace the component to avoid conflicts, it seems > like a valid strategy for customizing your component would be to > redefine portions of the model from the component in an entry in your > models directory. However, since the Rails $LOAD_PATH results in the > models directory entry not being read, this seems impossible. Am I > overlooking something/overlooking a better strategy to achieve this > functionality? Is there a particular reason for this ordering I''m > overlooking? > > > Thanks, > Fred > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- * J * ~
James Adam wrote:> I doubt that the ordering of the load paths in this particular case is > anything beyond an artefact of the order various parts of the Rails > framework are initialized, and as such it shouldn''t be a problem to > switch them around. > > Your best bet is to simply alter the $LOAD_PATH directly yourself, > such that the component paths are pushed after the application ones; > this shouldn''t be too hard to do, and could be shared between each of > your applications via a plugin (or just a single method in a file > somewhere). > > That said, it still wouldn''t be possible to redefine only portions of > the Foo class - Ruby will only load the first one it sees (either from > the application, or the component), and will completely ignore the > other. The overloading features that the engines plugin provides might > possibly help you, in some cases. > > - jamesThanks for the response. Turns out $LOAD_PATH is immutable, but you can work with config.load_paths in the initializer, which provided at least a stopgap solution. While Ruby won''t keep on searching, if you have the model from the app''s file loaded up first, you can do some variety of dependency via the ActiveSupport Dependencies class to include the component version, and it all works nicely (whereas the other way would require sacrificing a lot of portability in the component). -- Posted via http://www.ruby-forum.com/.
2006/7/20, Fred Wulff <fwulff@mobileevolution.com>:> > James Adam wrote: > > I doubt that the ordering of the load paths in this particular case is > > anything beyond an artefact of the order various parts of the Rails > > framework are initialized, and as such it shouldn''t be a problem to > > switch them around. > > > > Your best bet is to simply alter the $LOAD_PATH directly yourself, > > such that the component paths are pushed after the application ones; > > this shouldn''t be too hard to do, and could be shared between each of > > your applications via a plugin (or just a single method in a file > > somewhere).> > > That said, it still wouldn''t be possible to redefine only portions of > > the Foo class - Ruby will only load the first one it sees (either from > > the application, or the component), and will completely ignore the > > other. The overloading features that the engines plugin provides might > > possibly help you, in some cases. > > > > - james > > Thanks for the response. Turns out $LOAD_PATH is immutable, but you can > work with config.load_paths in the initializer, which provided at least > a stopgap solution. While Ruby won''t keep on searching, if you have the > model from the app''s file loaded up first, you can do some variety of > dependency via the ActiveSupport Dependencies class to include the > component version, and it all works nicely (whereas the other way would > require sacrificing a lot of portability in the component).$:, which should be equivalent to $LOAD_PATH, isn''t immutable. You can do $:.insert .. or $:.append. It''s used many time in Rails core. -- -- For rails performance tuning, see: http://railsexpress.de/blog Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060720/c49ac7ec/attachment.html