[imp] Dynamic mailer config based on FROM and TO addresses

Robin Bankhead horde at headbank.co.uk
Thu Oct 24 15:54:26 UTC 2013


Quoting Michael M Slusarz <slusarz at 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


More information about the imp mailing list