[jifty-devel] RFC: Design change in ClassLoader
John Peacock
jpeacock at rowman.com
Thu Jun 22 09:47:33 EDT 2006
I'm been fighting for the last couple of nights to write a successful
plugin, using the existing plugin framework, and to the extent that a
website app using the plugin is 100% functional I have succeeded.
However, the after battling a harmless error being issued by
Jifty::Util::require(), I've come to the conclusion that the design of
ClassLoader is flawed.
The short explanation is that there can be only one ClassLoader in @INC,
otherwise the automatic class generation will try and build Actions for
Models that the plugin does will not support, but that the other
ClassLoader (provided by Jifty itself) _will_ support. An error will be
emitted for those cases, even though some other class has already been
loaded to cover that case.
There are three ways that I can see to deal with this:
1) Change the log->error in Jifty::Util::require to be log->warn or even
log->debug, since the "error" is completely harmless and another class
will actually autogenerate and handle those Actions (this is the trivial
fix, but may hide true errors);
2) Create a more OO error system and only throw an error if a given
application class cannot be autogenerated by any method (this looks to
be a very significant architectural change to collect errors and pass
them up the chain);
3) Change the structure of ClassLoader so that additional hooks can be
dynamically added to the INC loop, so that as long as *any* class will
handle a given require(), the entire loop will succeed (this is my
preferred method).
Basically, what I'm suggesting is that Jifty::ClassLoader::INC be a loop
over a array of hashes, where each array element is a regex plus a
coderef. The core Jifty code would register the current half dozen or
so regexes via a new register_callback (or better name) sub. Then a
plugin, on load, would register its own additional regexes (either
before or after the system regexes). Then whenever the J::CL::INC was
called, it would just step through each regex in the array until it
found one that matched _and_ succeeded, then return that filehandle.
Only if no regex matched and succeeded would undef be returned, which
would normally mean that require() would throw an error. This is much
closer to the way that the Dispatcher is structured.
One additional thing that may be needed is a way to conditionally
require() a class without throwing an error. This is because, during
the maze of callbacks, a proposed class may be generated that a given
plugin won't support, but the only way to tell that is to try.
For example, I have a WebApp::Model::Post class, and during the initial
attempt to handle that, a Jifty::Plugin::Login::Model::Post class will
attempt to autogenerate. However, Jifty::Plugin::Login is only prepared
to support Jifty::Plugin::Login::Model::User, so that autogenerated
class will fail. Later on, the actual application class
WebApp::Model::Post is used by the Jifty hook to autogenerate
WebApp::Action::(Create|Update|Delete)Post.
Thoughts???
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
More information about the jifty-devel
mailing list