Quoting Michael M Slusarz <slus...@horde.org>:
For factories, Core tries to load the driver by appending to the base driver name and, if this fails, it tries to load the parameter as a class name. Note that the latter implies that the extended class can live anywhere, as long as it is autoloadable (i.e., you can store local classes in a horde/config/lib directory).
Can you clarify on this point: Is horde/config/lib a literal path? Does that permit to hook into Horde's own autoloading mechanism? I've been trying various permutations, and the only one that succeeds so far is locating and naming it in the same fashion as others, eg [hordedir]/lib/Ext/Smtpcustom.php class Horde_Ext_Smtpcustom extends Horde_Mail_Transport_Smtphorde {...} I can't replicate this from inside a config dir. (Apologies if I'm just over-inferring and/or being dense. Like when I didn't realise how old my testing codebase was, hence me not having known of your ...Smtphorde class!)
To ensure a class is autoloadable, just directly include/require the file at some point prior to the class being accessed.
Isn't that just manual loading?
It depends on whether you want to accurately report via sent-mail what the messages actually look like. If you don't care, this can be done within the mail class. If you want to report to the user that messages actually were sent in two different packages, you would need to edit/extend the compose class.
I don't care one bit ;) TBH I may just tell the users they can't do this, and just to forward the copy to local recipients if they need to. Think I will need to butcher Compose.php anyway though, since my class won't have access to the headers within itself at invocation time ... (Unless there is a way to retrieve them from its constructor?) Robin Bankhead -- imp mailing list Frequently Asked Questions: http://wiki.horde.org/FAQ To unsubscribe, mail: imp-unsubscr...@lists.horde.org