You're hardcore! Unless you mean UML or just prototype functions, which I also do from time to time. Except when I code by the seat of my pants which is more often than not.
Your "unless" is correct. Although I never really formally learned UML. I'm not that hardcore.
In the second code, you don't give what Filter is, so there is no way to know what code you are extending.
Ah... there are a lot of missing components, but I though it would be clear enough. The filter is fairly simple:
Code: Select all
<?php
//McGruff seems to think that InterceptingFilters are bad... and I'm starting
//to think that way too. But we need a controller first.
class Filter
{
//Always good to have a base class! It doesn't do much
var $_registry;
function Filter() {}
function execute(&$registry) {
$this->_registry =& $registry;
}
}
?>
And this code executes the filters:
Code: Select all
<?php
class FilterChain
{
var $_filters = array();
function FilterChain() {
$this->addFilter(new Filter_Registration());
$this->addFilter(new Filter_Authentication());
}
function addFilter(&$obj) {
$this->_filters[] =& $obj;
}
function processFilter(&$registry) {
$size = sizeof($this->_filters);
for($i = 0; $i < $size; $i++) {
$this->_filters[$i]->execute(&$registry);
}
}
}
?>
I like the PHP 5 model because it gives you the option of SPL, interfaces, abstraction, and visibility scope. You also get rid of the pointless &= when passing by reference. In PHP 5 classes are automatically passed by reference. It is up to you if you want to clone them.
Since we're really trying to design something beautiful rather than get something that will work on most PHP4 hosts, and plus, the host that I'm currently on gives me PHP 5 (although admittedly an old version: 5.0.4), we'll go PHP5. (I need practice in PHP5 anyway). However, we're still giving a keen eye to reusability and packagability.
I believe it should be more of a Factory or Singleton model.
Singletons, hmm... that would work like...
Code: Select all
class PropagateAuthWithSingleton implements PropagateAuthInterface
{
public function propogate($user_id) {
$singleton = Singleton::getInstance();
$singleton->setCurrentUser($user_id);
}
}
That said, the ACL can be a separate abstract class that can be extended or an Interface.
I guess I won't be able to get away with telling you people not to worry about the access control just yet.
I can see there is a plugin usage for the second example, but why? What purpose does it have?
It's more of a unit testing thing. By seperating the call to the dependency to another function, we always have the option of injecting a mock by partial mocks (SimpleTest is good reading for this, see:
http://www.lastcraft.com/partial_mocks_ ... tation.php )
--
So I've been sketching out a nebulous "Authentication Module" and the things it would have to interact with some way or another (even if it's through another layer).
* $_POST superglobal, which interacts with the login form
* $_SESSION superglobal
* Database with password, which interacts with user preferences to change passwords/emails and registration (registration, in turn, interacts with email for validation)
* Application context (sometimes bleeding in with $_SESSION) (interacts with Authorization)
We want to implement all these things, but anything outside the core should be able to be overloaded.