I recently had a project approved, without every recieving an email from them; you may want to keep that in mind...Quote:
Originally Posted by lastcraft
Printable View
I recently had a project approved, without every recieving an email from them; you may want to keep that in mind...Quote:
Originally Posted by lastcraft
Still waiting to see a stable release of a 'finished' PHP DI container really. There's real interest here in using it, but none at all in reinventing the wheel by developing our own one.
Forgive my ignorance if I've missed one, I've been in a meeting for several months. But last time I checked Pico came complete with broken tests, so I chose to hold off...
Phemto v2 sounds interesting, especially if can keep it to ~100 lines. The implemtation I have atm comes in at around ~180.
Hi...
Oops, wish I'd never said that :blush:. It's 150 at the moment, so it may end up at 250.Quote:
Originally Posted by Ren
yours, Marcus
p.s. CVS is up, but you now have to check everything out again :(. Looks like I'm in for an afternoon of file copying...
What's the URL for this?Quote:
Originally Posted by lastcraft
I'm guessing it will be http://sourceforge.net/projects/phemto/ .Quote:
Originally Posted by 33degrees
Until it's moved, you can get it from http://lamplib.cvs.sourceforge.net/lamplib/phemto/
Hi...
I haven't uploaded anything yet as I want to try the SF Subversion service. Also I want to get some SimpleTest fixes out and contact Pawel (of Pico) again, so it willbe a few weeks before I code the next version. I'll post a new thread once I have it back up.Quote:
Originally Posted by Ren
yours, Marcus
Sorry for taking so long...
> the factories could be locators as well, so it doesn't feel accurate.
Nope, the idea doesn't feel right to me either, some how though I can't put the explanation into words (yet) :(
> Was the ugly-part a joke, or do you really find the solution unsatisfactory?
Yer, the script I posted is ugly as it stands and I have since done a better implementation of it; I knew that I could... I just hadn't found the time back then, so now I'm a lot happier with the result.
PHP Code:include_once( 'configs/configs.php' );
// ...
// declare dependencies
Component::set( 'logger' );
Component::set( 'configs' );
Component::set( 'request' );
// note, i need to wrap the array with an instance of typeof IDataspace...
Component::get( 'iconfiguration' ) -> import( new Parameters( $configs ) );
My appologies for reviving a dead thread btw.PHP Code:// later...
$db = Component::get( 'iconfiguration' ) -> get( 'db' ); // database configuration
Hi...
There is now some code in CVS for phemto. It's currently 173 lines of code. This is still very much alpha code and the design and features may change radically. Anyway, comments would be appreciated...
http://sourceforge.net/projects/phemto/
It's a CVS pserver checkout currently. I'll get a tarball up in a couple of days.
yours, Marcus
I'm willing to take that apology, if you're willing to post more. ;)Quote:
Originally Posted by Dr Livingston
I'm at a stage in my framework where I'm seeing my code infested with ugly, ugly, repetitive wiring that really doesn't belong. I'm using a standard, non-static service locator right now, but it isn't doing me much in that respect. I'd be very interested in seeing whatever solutions you've come up with for yourselves.
lastcraft: Will definitely take a look as soon as I have time.
Hmm, I've been using a DI that the registry keys are defined a register() time. So can abuse it abit and do things like http://www.sitepoint.com/forums/show...49&postcount=1 .Quote:
Originally Posted by lastcraft
Definately think DI should be at the heat of a workflow type system, just haven't explored it further.
Oh, and if want to shave a few lines... :)
PHP Code:private function discoverInterfaces($class) {
$interfaces = array_merge(class_implements($class), class_parents($class));
$interfaces[] = $class;
return $interfaces;
}
How have people tackled the problem of LazyLoading with DI? With pico, I had to make a handle class which was aware of the container, which I think is a bad code smell. Has anyone else put more thought into this than me?
PHP Code:class PicoLazyProxy {
protected $pico;
protected $class;
protected $path;
protected $subject;
public function __construct($pico, $class, $path='') {
$this->pico = $pico;
$this->class = $class;
$this->path = $path;
}
protected function subject() {
if (!($this->subject instanceof View)) {
if (!class_exists($this->class)) {
require_once $this->path.$this->class.'.php';
}
$this->subject = $this->pico->getComponentInstance($this->class);
}
return $this->subject;
}
public function __call($method, $args) {
return call_user_func_array(array($this->subject(), $method), $args);
}
}
Hi...
I always want to shave a few lines...Quote:
Originally Posted by Ren
Now 168 lines :).PHP Code:private function discoverInterfaces($class) {
if (! class_exists($class)) {
throw new Exception("Cannot inject missing class $class");
}
return array_merge(
array($class),
class_implements($class),
class_parents($class));
}
yours, Marcus
Hi...
My solution is an even uglier hack, where a locator can be loaded that shortcuts the interface discovery. I already hate it.Quote:
Originally Posted by sweatje
I don't think lazy code loading works with these automated schemes. It may be that the efficiency comes from caching the interfaces after the first run.
How are you finding Pico?
yours, Marcus
My implementation doesn't do interface discovery, but rather relies on the key provided at register time.Quote:
Originally Posted by sweatje
PHP Code:class LazyLoadingLocator extends ComponentLocatorDecorator
{
private $loaded = false;
private $fileName;
function __construct(ComponentLocator $locator, $fileName)
{
parent::__construct($locator);
$this->fileName = $fileName;
}
function getInstance(DependancyInjector $injector)
{
if (!$this->loaded)
$this->loaded = class_exists($this->getImplementation()) || require($this->fileName);
return parent::getInstance($injector);
}
}
I can't say I have enought experience to comment. I feel like it usually takes two or three implementations usign a project to get a reasonable feel for the ins and outs of it. I used Pico on one project for handling the automatic wiring, and it perform well in that capacity. It seemed to work well in a testing mode as well, for example I was able to make a custom "assertDispach" assertion for use with actions and verify the correct action class was instanciated and called if a given action was requested.Quote:
Originally Posted by lastcraft