Quoting Robin Bankhead <ho...@headbank.co.uk>:
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?
It's any path you want it to be. I just suggest putting it in the
config folder, since that's where all the other local edits occur.
(It's best to put into a subdirectory also, since the base config
directory is populated with files that Horde may update/add in the
future).
Does
that permit to hook into Horde's own autoloading mechanism?
No. But there's no need to autoload.
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.
Again, there's no need to autoload. Just because we have an
autoloader doesn't mean that require can't be used. In this
particular case, it is a heck of a lot easier to simply require the
file directly instead of trying to manipulate autoloading to work.
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?
Yes. Again, there's nothing wrong with this. Autoloading is
important when you are distributing code. When you are doing
something locally, there's no problem to include a single file when
necessary.
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?)
Not sure what you mean by this(?) Extending a mail transport object,
you have access to all the outgoing headers of the message.
michael
___________________________________
Michael Slusarz [slus...@horde.org]
--
imp mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: imp-unsubscr...@lists.horde.org
