Hi...

Quote Originally Posted by dagfinn
Looking at the older part of this thread, I see I'm questioning some of the decisions that were made early. I understand how that might be annoying.
With 200 posts (at this one in fact!) some stuff will need reiteration and highlighting. In fact it is only by peer review that we will end up with anything good. Not sure I would want to go over the requirements again with every new person that signs up though (hint to lurkers) .

Quote Originally Posted by dagfinn
Here's an example from the thread's deep dark past,
PHP Code:
$authoriser = &new Authoriser($this->_configuration);
$edit = &$authorisor->createEdit(); 
My point is this: To create the Edit object which is in sync with the Authoriser, you have to keep $authoriser alive.
The original idea was to pass the configuration into the edit (later replaced by directly passing the data accessor). Because the edit set up is taken from the Authoriser they are guaranteed to be in sync, or talking to the same database at least. If the Authoriser is destroyed (this was what I was thinking) then the edit should still have a reference to everything it needs.

There are other ways to set up the edit object, but it would mean that both this and the Authoriser need a global access point for shared data (which is pretty much constant).

If you want to set the configuration with define() statements for now then that is fine for the moment. My feeling is that the storage class is the way to go, but I don't want to predujice the design right now. Something like this then...?
PHP Code:
define('DATABASE_ENGINE''Postgres');
define('DATABASE_NAME''rbac_authorisation');
define('TABLE_PREFIX''rbac_');
... 
These can be set up in the test runner script (developer dependent) rather than the test case script (shared source code). I am not a fan of doing things this way, but it is common enough in the PHP world that it is easy to understand.

yours, Marcus