Quote from: OpenGeek at Aug 21, 2005, 10:46 PM
Wouldn’t this be the job of a plugin; dynamically adding the $etomite object, making it available for the parser? I am not suggesting replacing the $modx object what so ever. Just interested in creating new objects with additional API’s to make available to the site resources. To override existing behavior is another subject, and one I’m not familiar enough with the parser to discuss intelligently at this point, though I imagine it would have to be done using the extenders approach. I was suggesting the ability to allow user-defined extenders to allow extensions to the parser, unless it could be solved using a module/plugin.
The problem is that at this point $modx already exists. So if you then load the alternate API, say, $etomite, which extends our core API $modx, you now have two different objects that don’t point to the same thing.
Whereas if you can do this via a config setting and do the include prior to the class initialization, you can do something like:
include "api/document.parser.inc.php";
include "api/etomite.parser.inc.php";
$etomite =& $modx = new Etomite_Document_Parser;
Now whether you use $modx or the alternate $etomite you point to the same object and are running off one copy.
Doing this after you have $modx started (and, hence, can run the plugins) means that you have to destroy your current class instance and recreate it.
Does that explanation make more sense?
MODX Staff
MODX Staff
