On Mon, Jun 23, 2008 at 9:56 AM, James Adam <[EMAIL PROTECTED]> wrote: > Hi Brian, > > Thanks for getting in touch - it's intruiging that we've not crossed > paths before :) Yes it is. I've havn't been on a project using Rails Engines for quite a while. > > It certainly seems like we share a lot of common goals. Keeping a > separate load path for the multi-file-loading (code-mixing in engines > parlance) sounds like a pretty good solution. I'd definitely be > interested in a patch to that effect. > > The one feature you highlight in your blog post that stand out to me > as something engines has avoided is plugin dependencies. I think I'd > probably continue to steer clear of that (particularly with the > continuing trend towards gemified plugins), unless a really > compelling, genuine example can be presented. Is this something you > have used in anger? No anger here. Plugin dependencies has been a part of Desert for a quite a while now (> 1 year). The plugin dependencies feature have been working very well in the case of Socialitis (Pivotal's social network platform). We have a sizable number of plugins (~ 10) that have dependencies on each other. These plugins also have dependencies on third party plugins. The nice thing about plugin dependencies is it also defines the proper load path order. In Desert, when require_plugin is called, it simply loads the parent plugin before the child plugin finishes loading.
At this time, I'm not sure if we are ready to take the plunge toward gemified plugins, but its certainly worth checking out. I think we opted not to use gems because we make heavy use of svn externals and piston to be up to date. > > What do you think? > > James Thanks, Brian > > On Mon, Jun 23, 2008 at 7:38 AM, Brian Takita <[EMAIL PROTECTED]> wrote: >> Hello, Recently I made a blog post about the Desert framework. >> http://pivots.pivotallabs.com/users/brian/blog/articles/459-build-your-own-rails-plugin-platform-with-desert >> >> In the comments, I learned that Desert is very similar to Rails >> Engines. Both projects have independently evolved along a similar path >> for the past 1 1/2 years. >> >> Anyways, one difference is the multi-file loading on const_missing, >> require, and load. Desert keeps a separate load path from Ruby. This >> load path includes all Rails app & plugin directories. >> When requiring a file, Desert will load all matches. If there was at >> least one match, then the require is finished. If there was not a >> match from the Desert load path, then Desert will delegate to Ruby's >> standard require method implementation, which loads the first file >> match. >> >> This allows models to be included in the multi-file loading sequence. >> Have you thought of such an approach? Do you think this would improve >> Rails Engines? If yes, I'd be happy with submitting a patch. >> >> Anyways, I think its possible that we may want to deprecate Desert in >> favor of Rails Engines. I'm wondering if there are fundamental >> differences between these two libraries, or if these projects are >> trying to solve the same problems with the same approaches. >> >> Thanks, >> Brian >> _______________________________________________ >> Engine-Developers mailing list >> [email protected] >> http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org >> > > > > -- > * J * > ~ > _______________________________________________ > 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
