On Nov 7, 2005, at 2:29 PM, Pat M. wrote:
thing…when you install the Typo engine, it automatically installs
different engines in for the very simple functionality.
Yes!
I think this is a great idea. I was thinking of the very same thing
when I started with the Typo Engine project. There are still a lot
of pieces yet to be put in to place, but we can move in this
direction. I’ve started with a patch that gives the template
rendering methods a “chain of command” so that templates will be
rendered from alternate directories if not found in the view’s
primary location [1].
Thinking about this further, here’s what still needs to be done to
make recursive engines a reality:
- Routes need some kind of recursive configuration ability.
As they are, routes limit us in two significant ways:
a. They are configured once (at boot-time) and in one location
only (routes.rb’s draw method call).
b. They assume an absolute base path from which each route is
interpreted.
The first limitation has (possibly?) been overcome by the productized
Rails source code–there are some methods I wrote in that gem that
permit second-tier applications to re-open the routes table and add
their own rules from within a separate routes.rb file.
Overcoming the second limitation has not (to my knowledge) been
attempted. The problem is that a route such as this:
map.connect ‘articles/page/:page’,
:controller => ‘articles’, :action => ‘index’,
:page => /\d+/
has an assumed base path: ‘/’. What would be useful is if we could
set up a route in the main routes.rb file that then passes off
control to a sub-router. For example:
config/routes.rb:
ActionController::Routing::Routes.draw do |map|
map.connect ‘blog/*anything’, :rerouter => ‘TypoEngine::Routing’
end
vendor/plugins/typo_engine/config/routes.rb:
class TypoEngine::Routing < ActionController::Routing
# Not sure what goes here… maybe some way to prepend a
# ‘/typo/’ module to all controllers?
end
TypoEngine::Routing::Routes.draw do |map|
map.connect ‘:controller/:action/:id’
end
This might work, but then it assumes that sub-engines need to know
nothing of their parent. Ideally, routing should be just one
attribute of the recursive engine configuration tree.
- We need a globally accessible “this_engine” variable.
This has come up all over the place as I’ve tried to make Typo in to
a well-behaved engine. What I’m talking about is a way of accessing
everything to do with the engine (including its relationship to other
engines) in a object-oriented “self” or “this” kind of way.
For example, in Typo there is a “#{RAILS_ROOT}/themes” folder unique
to that application. Models, Views and Controllers, as well as any
config modules or libraries all need to access the configuration
information that pertains to “this engine”.
Using this_engine.parent or this_engine.children I imagine we could
also gain access to the configuration information pertaining to
related engines.
- Something has to be done about namespace pollution.
Typo has more than 20 models, including such generic ones as
“Category”, “User” and “Tag”. Undoubtedly this is going to cause
some problems when integrating in to other applications. So far, I
haven’t found a really elegant way of fixing this problem. Should we
just require that engine developers prepend the engine name in front
of all model and controller classes?
For example:
/vendor/plugins/typo_engine/app/models/category.rb:
class Typo::Category < ActiveRecord::Base; end
/vendor/plugins/typo_engine/app/models/tag.rb:
class Typo::Tag < ActiveRecord::Base; end
etc.
(Does anyone know if this can be done currently?)
And for controllers:
/vendor/plugins/typo_engine/app/controllers/typo/articles_controller.rb:
class Typo::ArticlesController < ApplicationController; end
/vendor/plugins/typo_engine/app/controllers/typo/admin/
blacklist_controller.rb:
class Typo::Admin::BlacklistController < ApplicationController; end
- The engines plugin needs to load recursively.
The engines plugin would have to load engines recursively. I’m sure
there are some other issues involved with this step that I haven’t
thought of yet.
- Other issues: What about library version conflicts?
Typo has several dependencies, all in the vendor directory. What if
an application needs one version of RubyPants while the Typo engine
needs another?
I don’t think I could implement any of this really, and not sure if
I’ve explained it well enough…hopefully James A.s, and whoever
else may decide to contribute, can use this as a launching pad of
sorts.
Ideas are good… source code is better! 
Duane J.
(canadaduane)
[1] Peak Obsession
