[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 



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