Question About Application Structure/Components and "other" Classes

[mitkola]

Hi Konstrukt fans,

I'm newly to Konstrukt and I'm very impressed from implementation
architecture and ideas.

In my application there are many classes that not extend k_Component.
I want to use debug functionality that is used in k_Component (like
debug method) and respective k_Bootstrap, but from classes that not
extend k_Component.
Which is recommended approach for this?

I have also another question about instance of k_MultiDebugListener.
When k_DefaultComponentCreator is created, in its constructor is
created k_MultiDebugListener.
function __construct(...
$this->setDebugger(new k_MultiDebugListener());
...
}
From other side in k_Bootstrap's run() method is created
k_MultiDebugListener which replace ComponentCreator's debugger.
function run(....
$debugger = new k_MultiDebugListener();
$this->components()->setDebugger($debugger);
....
}
I this case I think that instantiated in k_DefaultComponentCreator
k_MultiDebugListener is excessive.
Is this correct?

Thank you for the help and assistance.

Regards,

Dimitar Angelov

[Troels Knak-Nielsen]

Hi Dimitar,

The debugger is really quite specific for logging information about the framework/http activity. I wouldn't recommend that you use it as a general system-wide debug log. What is the scenario you're looking to use it in?

On 24 November 2011 14:53, mitkola <mit...@gmail.com> wrote:

I have also another question about instance of k_MultiDebugListener.
When k_DefaultComponentCreator is created, in its constructor is
created k_MultiDebugListener.
function __construct(...
   $this->setDebugger(new k_MultiDebugListener());
...
}
From other side in k_Bootstrap's run() method is created
k_MultiDebugListener which replace ComponentCreator's debugger.
function run(....
   $debugger = new k_MultiDebugListener();
   $this->components()->setDebugger($debugger);
....
}
I this case I think that instantiated in k_DefaultComponentCreator
k_MultiDebugListener is excessive.
Is this correct?

You're right, but I don't think it is very important. You would generally just create a single instance of a component creator per php process, so a single excess object instantiated is a drop in the ocean. Having it this way ensures that there will always be a debugger, even if the creating context fails to provide one. It's like a default value.

-- 

troels

[mitkola]

Than you for the answer Troels!

Yes you are right about debugger that is specific to framework and is
not good idea to use it from surrounded classes, but this is little
useful when I want to send some debug information to the browser from
my classes outside of components hierarchy.
I can generalize structure as follow.
My Root component (which is always instantiated) can implement some
methods for global error reporting (particular to the client), logging
and so on.
At first time I was made following to my Root component (this is part
for debugger, but may be used and for other cases):
class Root extends k_Component {
static protected $RootInstance;

function __construct(TemplateFactory $templates) {
if (!isset(self::$RootInstance))
self::$RootInstance = &$this;
}

protected function _getDebugger() {
return $this->debugger;
}

static public function getDebugger() {
if (isset(self::$RootInstance)) {
return self::$RootInstance->_getDebugger();
} else
return NULL;
}
...
}
Next I've created base class which is in some kind 'linked' with Root
component:
abstract class ARooted {
protected $debugger;

function __construct() {
$this->debugger = Root::getDebugger();
}

protected function debug($mixed) {
if ($this->debugger)
$this->debugger->log($mixed);
}

protected function error($mixed) {
$this->debug($mixed);
}
protected function warning($mixed) {
$this->debug($mixed);
}
protected function notice($mixed) {
$this->debug($mixed);
}
}

Is this well solution or it is with inconsistency of design
principles?

Regards,

Dimitar Angelov

On Dec 9, 12:09 am, Troels Knak-Nielsen <troel...@gmail.com> wrote:
> Hi Dimitar,
>
> The debugger is really quite specific for logging information about the
> framework/http activity. I wouldn't recommend that you use it as a general
> system-wide debug log. What is the scenario you're looking to use it in?
>

> troels