[dev] Horde_Url, dependency injection and factories. was: [commits] Horde branch master updated. 7f6ddcffe1c3d9031d499c0dee40f8b37628e5c5

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> In 95% of the cases, if not more, the URL object should finally be  
>> casted to a string automatically, either by echo'ing or by string  
>> concatenation. We still have to catch the places where it doesn't.
>> But of course, in the long term, we should change everything to  
>> directly use Horde_Url. But that's a huge number of places, so I  
>> implemented it for best possible BC, so we can phase out  
>> Horde::url() and ::link() step by step.
>
> How are we going to be able to phase out Horde::url()?  It does some  
> horde-config specific URL generation that really doesn't belong in a  
> general purpose library that Horde_Url appears to be.

Not completely phasing out, but just being a wrapper around Horde_Url  
that does the horde-specific stuff. Maybe it could even be merged wit  
applicationUrl(). This would also allow easier chaining, because PHP  
unfortunately doesn't support de-referencing of constructors (right?).

So we end up with code like:

echo Horde::url($someurl)
     ->remove('foo')
     ->add('bar', 'baz')
     ->link(array('title' => 'Foo', 'att1' => 'xyz'));

Much cleaner then
echo  
Horde::link(Util::addParameter(Util::removeParameter(Horde::url($someurl),  
'foo'), 'bar', 'baz'), 'title', '', '', '', '', '', array('att1' =>  
'xyz'));

An idea I spawned on IRC yesterday was to use a special naming for  
factories like these methods that always return objects of a certain  
class:

Horde::Url() as a Horde_Url factory
Kronolith::Driver() as Kronolith_Driver factory (what  
Kronolith::getDriver() does now)

The idea is to intuitively map factory names to class names and to  
only use these for factories that we need to inject dependencies into  
general purpose objects. I do *not* want to use it for general  
factories on the library level. Just for wrappers that inject  
horde-specific stuff.

Chuck was arguing against that though, and is going to come up with an  
alternative approach. I'm of course open for better ideas to provide  
dependency injection without having to deal with Horde_Injector in  
such often-used throw-away classes like Horde_Url. But so far, I like  
my idea the best, because it's the only one. :)

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/