Hi Brian, Thanks for getting in touch - it's intruiging that we've not crossed paths before :)
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? What do you think? James 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
