Jump to content

Recommended Posts

You're trying to be insulting again. "Chill out", I'm not annoyed/angry. "Now don't get mad at me for telling it how I see it, there is not one right way unless you're a Christian and quoting the bible. Maybe you should be a little less caught up with OOD heuristics and start thinking for yourself." How utterly condescending of you.

 

The debate isn't purely about registry vs the rest; it's about globals vs the rest.

 

Data mapper or DAO - and infact every - object ever created only cares about the interface of another object. To extend your example of a user, dao and datamapper; none of them need to know anything about any object they relate to, other than if they fit the interface.

 

Node path's are no more than 3 or 4 deep, at the very worst. If your node path's extend further than 3 you should really consider redesigning as a rule of thumb. Some exceptions such as ORM examples do exist. If not a registry, then your controller should be instantiating objects and passing to the sub-components. Something like:

<?php
class 
{
    public function run ()
    {
        $this->_view = new View();
        $this->_view->display(new Model());
    }
}
?>

is fine. Encapsulation is not broken; the View object does not know what the Model object is, except that it fits the expected interface. The controller is doing it's job, controlling which nodes are invoked.

 

and just adding this as I was typing the above whilst two more replies came in..

utexas_pjm.. yes, that's also a perfectly acceptable use of the registry.

 

"The point goes beyond the Domain Model. After posting that I realized that it was probably not the best example example of the problem. In fact, I was a bit disappointed in Jenk for not noticing and banging me down for it.  :P" I refer you to my first comment.

 

Oh, come on dude, relax, please! Nobody's taking the piss at you, we're just having a friendly discussion.

 

Edit: ok, I can see the condescending bit, but it's just my response to you seeing every OOD heuristic as a fact of life. It wasn't meant as offensive.

This thread has made me reevaluate my own use of my Registry. I'm currently working on a view system loosely based on Fowlers 2-step Transform View.

 

The reason why I am posting this in this thread is because of cases like this one:

 

class Message implements Map_Component {

private $string = '';

public function __construct($subset, $msgId){

	$doc = Xml_Document::load(Registry::get('Config')->messageFile);
	$this->string = $doc->getElementById($subset.$msgId).nodeValue;
}
public function __toString(){
	return $this->string;
}
}

 

Basically a View map consists defines how visual components are ordered and fetched:

 

<message id="loginMessage">
<component target="message">
	<arg>user</arg>
	<arg>
		<ref>user::getStatus</ref>
	</arg>
</component>
</message>
</div>

 

In the first step, these components are transformed into domain data:

 

class View_Map_Component {

private $component;

public  function __construct(Xml_Element $element){
	$argElems = $this->$componentNode->getElementsByTagName('arg');
	$args = array();
	foreach($argElems as $argElem){
		$args[] = $this->parseArg();
	}
	try {
		$refl = new ReflectionClass($componentNode->getAttribute('target'));
		if(!$refl->isSubclassOf('Map_Component')){
			throw new View_Map_Exception('Invalid component: '.$refl->getName());
		}
	}
	catch(ReflectionException $e){
		throw new View_Map_Exception($e->getMessage());
	}
	$this->component = $refl->newInstance($args);
}
private function parseArg($argNode){
	$refs = $argNode->getElementsByTagName('ref');
	$str = $argNode->nodeValue;

	foreach($refs as $ref){
		$command = array_combine(
			array('index','call'), explode('::', $ref->nodeValue)
		);
		//Still working on this to accept more complex structures
		$str .= call_user_func(array($this->refs[$command['index']], $command['call']));
	}
	return $str;
}
public function __toString(){
	return $this->component->__toString();
}
}

 

So the above fragment of a map would query Message and User. At this stage, processing of the Domain Model is complete (so User::getStatus() would return the appropriate status code), but in order for Message to be able to return the correct message string (in the correct language) it has to have a reference to at the very least a Config of Settings object to know where to get the string from, or acquire the setting statically which makes it equally global.

 

The second step does little more than transform the map into XHTML.

 

One alternative is to pass a Registry from the controller through View_Map and View_Map_Component to Message, but as you can probably guess by reading some of my earlier posts, that 'solution' doesn't really appeal to me. These classes do not need the Registry, I don't want to make them responsible for passing something that it not directly relevant to them.

 

On a sidenote: what I'm doing in the map vaguely reminds me of SOAP... Anyone know of an XML standard that would fit my need? Better to use a standard than hurt my brain over the best XML schema.

Ha! LOL... Yeah, I do that sometimes. This code has not exactly been tested, I'm still modeling.

 

Naturally using SOAP is tempting, namely because I could use the SOAP extension and free myself of writing a boring parser class.

 

But using the SOAP extension the requests have to be made over HTTP.

 

I could write my own SOAP server which optionally excepts file system calls, but then I'd rather use something that is a little more suited for the task (i.e. not explicitly intended for a server-model architecture).

 

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.