I'm trying to redefine exception handler for a couple of my controllers in Zend (RESTful).
This is my piece of code:
abstract class RestController extends Zend_Rest_Controller
{
public function init()
{
set_exception_handler(array($this, 'fault'));
}
public function fault($exception = null, $code = null)
{
echo $exception->getMessage();
}
}
But for some reason Zend uses default template/error handling and my fault function didnt execute.
Btw, I'm using module architecture. that controller is from rest module.. Zend's default error handler is from default module.
This is an interesting question. I'm not totally sure at the moment so I'm going to research this one a bit and see what I come up with. For now there are workarounds that aren't too ghetto either. One way would be to create an abstract controller from which to extend all of your controllers in your rest module.
abstract class RestAbstractController extends Zend_Rest_Controller
{
final public function __call($methodName, $args)
{
throw new MyRestException("Method {$methodName} doesn't exist", 500);
}
}
// the extends part here is optional
class MyRestException extends Zend_Rest_Exception
{
public function fault($exception = null, $code = null)
{
echo $exception->getMessage() . ' ' . __CLASS__;
exit;
}
}
class RestController extends RestAbstractController
{
// method list
}
Also, I found this interesting article: http://zend-framework-community.634137.n4.nabble.com/Dealing-with-uncatched-exceptions-and-using-set-exception-handler-in-Zend-Framework-td1566606.html
Edit:
Somewhere in your bootstrap file you will need to add this:
$this->_front->throwExceptions(true);
$ex = new MyRestException();
set_exception_handler(array($ex, 'fault'));
The first line there should effectively turn off Zend's exception handling, the only thing missing is a control structure to determine if the current request is for your REST service or not. NOTE The reason this had to go in the Bootstrap.php file was that your call to set_exception_handler() in the init() function was never reached because Zend Framework threw the exception first. Placing that in the bootstrap file will counter that.
Finally solved the problem by myself :)
From Zend documentation:
Zend_Controller_Front::throwExceptions()
By passing a boolean TRUE value to this method, you can tell the front
controller that instead of aggregating exceptions in the response
object or using the error handler plugin, you'd rather handle them
yourself
So, correct solution is this:
abstract class RestController extends Zend_Rest_Controller
{
public function init()
{
$front = Zend_Controller_Front::getInstance();
$front->throwExceptions(true);
set_exception_handler(array($this, 'fault'));
}
public function fault($exception = null, $code = null)
{
echo $exception->getMessage();
}
}
We just have to add
$front = Zend_Controller_Front::getInstance();
$front->throwExceptions(true);
before set_exception_handler to make it work.
Related
I am trying to make an implementation of the Bridge Design Pattern, following the steps on Tutorials Point. I am converting the code from Java to PHP and changing some names.
The problem is, when I try to pass the concrete bridge implementer class to the concrete class implementing interface, an error is throw.
My code is as follows:
// LaunchApi.php
interface LaunchApi
{
public function launch();
}
// RedEngine.php
class RedEngine implements LaunchApi
{
public function launch()
{
echo "The red engine is really fast!!!";
}
}
// Rocket.php
abstract class Rocket
{
protected $launchApi;
protected function __construct($launchApiImplementer)
{
$this->launchApi = $launchApiImplementer;
}
public abstract function launch();
}
// FullRocket.php
class FullRocket extends Rocket
{
public function __construct($launchApi)
{
parent::__construct($launchApi);
}
public function launch()
{
$this->launchApi->launch();
}
}
// LaunchingScript.php
$redEngine = new RedEngine();
$redEngine->launch(); // this works
$redRocket = new FullRocket($redEngine);
$redRocket.launch(); // this won't work
The error throw is:
design-patterns\Bridge>php LaunchingBridge.php
The red engine is really fast!!!
Fatal error: Call to undefined function launch() in \design-patterns\Bridge\LaunchingBridge.php on line 24
I tried to pass by reference using the &, but it only changes the error.
yeah should be $redRocket->launch(); instead of $redRocket.launch();
like what nigel ren said
I am writing some code (a database abstraction layer, to be used in other of my code modules) that I would like to release as a standalone module that may be included in a project with composer. I would like to include in the composer defintion some suggested modules that would improve the performance of my module, but that are't required.
The problem I have is how to do this in a way that is note completely horrific.
So in this particular example the module is declared in namespace Intahwebz\DB; and then the optional module Intahwebz\Log\Log is tried to be included, which in turn tries to use the optional module Monolog.
What I have so far is the module code ConnectionWrapper.php
namespace Intahwebz\DB;
use Intahwebz\Log\Log;
if(trait_exists("Intahwebz\Log\Log") == false){
require_once("Log.php");
}
class ConnectionWrapper{
use Log;
function __construct(){
$this->initLog();
// Rest of constructor code.
$this->log->trace("ConnectionWrapper has been constructed.");
}
// Lots of other functions here.
}
?>
Then in Log.php I check to see if Monolog is available and if so include it, otherwise define a really lightweight logger.
<?php
namespace Intahwebz\Log;
if (class_exists('Monolog\Logger') &&
class_exists('Monolog\Handler\StreamHandler')) {
require_once "MonologWrapper.php";
}
else{
class Logger{
public function debug($message, array $context = array()){
echo $message."\n";
}
public function log($level, $message, array $context = array()){
echo $message."\n";
}
public function info($message, array $context = array()){
echo $message."\n";
}
public function notice($message, array $context = array()){
echo $message."\n";
}
public function warning($message, array $context = array()){
echo $message."\n";
}
public function error($message, array $context = array()){
echo $message."\n";
}
public function critical($message, array $context = array()){
echo $message."\n";
}
public function alert($message, array $context = array()){
echo $message."\n";
}
public function emergency($message, array $context = array()){
echo $message."\n";
}
}
trait Log{
var $log;
function initLog(){
$this->log = new Logger(__CLASS__);
}
}
}
If Monolog is available, we use it by including MonologWrapper.php
<?php
namespace Intahwebz\Log;
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
trait Log{
var $log;
function initLog(){
$this->log = new Logger(__CLASS__);
//Todo - get log handler from config file automagically.
$this->log->pushHandler(new StreamHandler(PATH_TO_ROOT.'var/log/Admin.log', Logger::WARNING));
}
}
?>
The problems with this are:
1) It's incredibly ugly, and requires an extra files per suggested module.
2) It doesn't allow people to switch in a different logger other than monolog without re-writing code.
3) It has duplicate class/trait definitions separated only by if statements, which completely confuses my IDE.
I know that the way Symfony et al solve this problem is by having a service layer. However I can't see how to use that design pattern without forcing the dependency inclusions to be a lot more complicated than they ought to be for just bringing in an optional module.
Can anyone describe a decent design pattern for including optional modules, or replacing them with other compatible modules? Or is this the type of thing that can only be defined nicely within an actual framework?
Dependency Injection :)
For example instead of
function initLog(){
$this->log = new Logger(__CLASS__);
// ..
}
use
function setLogger(Logger $logger) {
$this->log = $logger;
// ...
}
And so on. There are too many of this hardcoded dependencies, that I'm not going to mention everyone.
class MonologLoggingConnectionWrapperWrapper extends ConnectionWrapper {
public function __construct (ConnectionWrapper $wrapper, Logger $logger) {
// ..
}
}
Now Monolog is only required, when someones tries to instanciate this class and then it is quite obvious, that something is missing. If you like you can add a test to the file before the class definition, that should (in this case) throw an Exception, or trigger an error.
(The classname results from the fact, that ConnectionWrapper is not really a wrapper, but a class on it's own: A wrapper must extends the wrapped classes, or implements the corresponding interface, thus it is cleanly exchangeable)
Worth to mention: Avoid conditional class-, or function-definitions :) One Classname, one class (not more) and when I try to instanciate a class, it either exists, or not, but not "sometimes".
Is this how you would pass a value ("username" in example below) to a custom exception? The question being Would I use __construct()? Is using a custom exception for checking whether an important variable is set an overkill?
class customException extends Exception {
public function __construct($e) {
parent::__construct($e); // makes sure variable is set? [1]
$this->e = $e;
}
public function redirect_user() {
if($this->e === "username") {
header("Location: ");
}
}
}
class testing {
public function test() {
try {
if(!isset($_POST['username'])) {
throw new customException("username");
}
}
catch(customException $e) {
$e->redirect_user();
}
}
}
[1] http://php.net/manual/en/language.exceptions.extending.php#example-266
On a side note, what's the purpose of parent::__construct($e)? Wouldn't that be redundant?
There is no reason for your constructor at all. I would suggest using $this->getMessage() to access the value you are trying to set to $this->e.
So do something like this:
class customException extends Exception {
public function redirect_user() {
if($this->getMessage() === "username") {
print_r("Header");
}
}
}
It is much more straightforward and only extends the functionality of the base class rather than unnecessarily overriding the constructor.
That being said, I personally don't like the thought of using exceptions to execute application flow logic like you are doing. To me, custom Exceptions are useful to interface with custom logging systems, or to be able to log aspects of your application's state that are not available via the default Exception class.
I have the following code in file called AbstractClass.php in the libraries folder
abstract class AbstractClass {
abstract protected doSomething ();
}
class ConcreteClass extends AbstractClass {
public function doSomething () {};
}
When I try to load the AbstractClass from controllers as follows:
$this->load->library('AbstractClass');
I get Unable to load the requested class: AbstractClass error.
What am I doing wrong? Should I just include the file rather than loading it?
Thanks
Well obviously you cannot load an abstract class directly as this goes against the point of an abstract class.
You can put an abstract class in a file along with another library, but that is a bit pointless and goes against the "one class one file" standard that CI (and all good standards) suggest.
You can include this file with an include() in your library files, or set up an __autoload() function to do it for you. Best place for an __autoload() is the bottom of config.php.
I use abstract classes with CodeIgniter libraries because I have common methods which I want all inherited classes to use which are meaningless on their own. I don't know if what I'm about to suggest is best practise. I suspect it's not, but I personally find it useful. Here's how I do it:
Create a new classes folder in the CodeIgniter application folder.
Add this folder to the path. (I usually do this in the controller.)
if (!strstr(get_include_path(), APPPATH . 'classes')) {
ini_set('include_path', get_include_path() . ':' . APPPATH . 'classes');
}
Create the abstract classes, or other classes, in the classes folder.
Create an extended CodeIgniter library:
require_once('an_abstract_class.php');
class concrete_library extends an_abstract_class {
Use the library as normal:
$this->load->library('concrete_library');
That should do the trick. I hope this is useful.
Ok. I know this is WAY late, but I'm sure many people are having questions about this.
This is actually a limitation of the core Loader class, as it attempts to instantiate each of the items defined by the first parameter. As we all know, Abstract Classes by their very definition are Abstract and CANNOT be instantiated. So how do we get around this?
But most importantly: How do we get around this while conforming to the CodeIgniter Standards?
Since I've only just started using CodeIgniter, I can't really say for certain how Core Extensions were handled in the past. However, in the most recent version, the CodeIgniter framework will allow you to extend and override its core classes by Prefixing the filename with your defined Subclass Prefix (in most cases "MY_") followed by the name of the file you plan on extending.
*/application/core/MY_Loader.php*
<?php
if(!defined('BASEPATH')) exit('No direct script access allowed');
class MY_Loader extends CI_Loader{
public function __construct(){
parent::__construct();
}
}
?>
Chances are good that if you know how to utilize Abstract Classes, you know what this does. Basically, this Class now inherits all properties and methods of the original CI_Loader class. The code snippet above is technically an exact duplicate of the original Loader Class, but the most important thing here is that now this class will take over all load methods rather than the original.
Now all we need to do is provide the loader class with the means to know if it's loading and instantiating a concrete class, or if it's simply including an abstract class.
There are two methods that handle the loading of any Libraries:
Method 1) public function library
Method 2) protected function _ci_load_class
Method 1 handles the processing of all parameters passed to it by iterating through itself if the first parameter is an array, makes sure the data provided is clean, and prevents any actions from being taken if certain criteria aren't met.
Method 2 handles the actual loading of the necessary assets, error handling, etc.
We can override the behavior of methods 1 and 2 by redefining them within our new MY_Loader Class. I've done this by creating almost exact replicas of the original methods, but with the addition of a 4th parameter that - when true - will prevent the Loader from instantiating the defined Library Class in the second method. I've also included an additional method public function abstract_library that will allow you to explicitly define the Library as Abstract in shorthand fashion.
The following is the MY_Loader.php class in its entirety. This will not affect any existing calls to the library method.
Hope this helps!
*/application/core/MY_Loader.php*
<?php
if(!defined('BASEPATH')) exit('No direct script access allowed');
class MY_Loader extends CI_Loader{
public function __construct(){
parent::__construct();
}
public function library($library = '', $params = NULL, $object_name = NULL, $is_abstract=false){
if(is_array($library)){
foreach ($library as $class){
$this->library($class, $params);
}
return;
}
if($library == '' OR isset($this->_base_classes[$library])){
return FALSE;
}
if(!is_null($params) && ! is_array($params)){
$params = NULL;
}
$this->_ci_load_class($library, $params, $object_name, $is_abstract);
}
public function abstract_library($library=''){
$this->library($library, NULL , NULL, true);
}
protected function _ci_load_class($class, $params = NULL, $object_name = NULL, $is_abstract=false)
{
$class = str_replace('.php', '', trim($class, '/'));
$subdir = '';
if(($last_slash = strrpos($class, '/')) !== FALSE){
$subdir = substr($class, 0, $last_slash + 1);
$class = substr($class, $last_slash + 1);
}
foreach(array(ucfirst($class), strtolower($class)) as $class){
$subclass = APPPATH.'libraries/'.$subdir.config_item('subclass_prefix').$class.'.php';
if(file_exists($subclass)){
$baseclass = BASEPATH.'libraries/'.ucfirst($class).'.php';
if (!file_exists($baseclass)){
log_message('error', "Unable to load the requested class: ".$class);
show_error("Unable to load the requested class: ".$class);
}
if(in_array($subclass, $this->_ci_loaded_files)){
if(!is_null($object_name)){
$CI =& get_instance();
if(!isset($CI->$object_name)){
return $is_abstract ? true : $this->_ci_init_class($class, config_item('subclass_prefix'), $params, $object_name);
}
}
$is_duplicate = TRUE;
log_message('debug', $class." class already loaded. Second attempt ignored.");
return;
}
include_once($baseclass);
include_once($subclass);
$this->_ci_loaded_files[] = $subclass;
return $is_abstract ? true : $this->_ci_init_class($class, config_item('subclass_prefix'), $params, $object_name);
}
$is_duplicate = FALSE;
foreach ($this->_ci_library_paths as $path){
$filepath = $path.'libraries/'.$subdir.$class.'.php';
if(!file_exists($filepath)){
continue;
}
if(in_array($filepath, $this->_ci_loaded_files)){
if(!is_null($object_name)){
$CI =& get_instance();
if(!isset($CI->$object_name)){
return $is_abstract ? true : $this->_ci_init_class($class, '', $params, $object_name);
}
}
$is_duplicate = TRUE;
log_message('debug', $class." class already loaded. Second attempt ignored.");
return;
}
include_once($filepath);
$this->_ci_loaded_files[] = $filepath;
return $is_abstract ? true : $this->_ci_init_class($class, '', $params, $object_name);
}
} // END FOREACH
if($subdir == ''){
$path = strtolower($class).'/'.$class;
return $this->_ci_load_class($path, $params, $is_abstract);
}
if($is_duplicate == FALSE){
log_message('error', "Unable to load the requested class: ".$class);
show_error("Unable to load the requested class: ".$class);
}
}
}
?>
Loading an abstract library:
<?php
$this->load->library("My_Abstract_Library", NULL, NULL, true);
/* -- OR -- */
$this->load->abstract_library("My_Abstract_Library");
?>
I haven't seen any examples around the web of Abstract classes with CI so I wanted to confirm that you can have an Abstract library. There are very good reasons which are fundamental to OOP as to why Abstract classes are useful. Fundamentally for me to ensure the child classes follow certain consistencies.
Let me know if you need an example, as you manually have to include the abstract class make sure you only do it once so you don't get issues with redeclaring classes.
Also don't forget if you have a static function or variable in the Abstract class you can still access it directly without having to load the class as in the below
AbstractClass::static_method_you_want_to_call();
I have found a simple way to use an abstract classes in Codeigniter. Just follow these steps. Go to libraries in system folder
Create an abstract class and dont link it with CI just name it with simple word without CI_
Create an another class name it with the same word as you give name to your file. As shown in code below
Extend that class with abstract class.
Then call abstract class function through your CI_class.
System -> libraries -> lib.php
abstract class B
{
public function lib1()
{
echo "This is library 1";
}
public function lib2()
{
echo "This is library 1";
}
}
class CI_lib extends B
{
public function libs(){
$this->lib1();
}
}
Then call that lib from Controller.
I have a PHP web application built with CodeIgniter MVC framework. I wish to test various controller classes. I'm using Toast for unit testing. My controllers have no state, everything they process is either saved into session or passed to view to display. Creating a mock session object and testing whether that works properly is straightforward (just create a mock object and inject it with $controller->session = $mock).
What I don't know, is how to work with views. In CodeIgniter, views are loaded as:
$this->load->view($view_name, $vars, $return);
Since I don't want to alter CI code, I though I could create a mock Loader and replace the original. And here lies the problem, I cannot find a way to derive a new class from CI_Loader.
If I don't include the system/libraries/Loader.php file, the class CI_Loader is undefined and I cannot inherit from it:
class Loader_mock extends CI_Loader
If I do include the file (using require_once), I get the error:
Cannot redeclare class CI_Loader
Looks like CI code itself does not use require_once from whatever reason.
Does anyone here have experience with unit testing CodeIgniter powered applications?
Edit: I tried to inject a real loader object at run-time into a mock class, and redirect all calls and variables with __call, __set, __get, __isset and __unset. But, it does not seem to work (I don't get any errors though, just no output, i.e. blank page from Toast). Here's the code:
class Loader_mock
{
public $real_loader;
public $varijable = array();
public function Loader_mock($real)
{
$this->real_loader = $real;
}
public function __call($name, $arguments)
{
return $this->real_loader->$name($arguments);
}
public function __set($name, $value)
{
return $this->real_loader->$name = $value;
}
public function __isset($name)
{
return isset($this->real_loader->$name);
}
public function __unset($name)
{
unset($this->loader->$name);
}
public function __get($name)
{
return $this->real_loader->$name;
}
public function view($view, $vars = array(), $return = FALSE)
{
$varijable = $vars;
}
}
Alternatively, you could do this:
$CI =& get_instance();
$CI = load_class('Loader');
class MockLoader extends CI_Loader
{
function __construct()
{
parent::__construct();
}
}
Then in your controller do $this->load = new MockLoader().
My current solution is to alter the CodeIgniter code to use require_once instead of require. Here's the patch I'm going to send to CI developers in case someone needs to do the same until they accept it:
diff --git a/system/codeigniter/Common.php b/system/codeigniter/Common.php
--- a/system/codeigniter/Common.php
+++ b/system/codeigniter/Common.php
## -100,20 +100,20 ## function &load_class($class, $instantiate = TRUE)
// folder we'll load the native class from the system/libraries folder.
if (file_exists(APPPATH.'libraries/'.config_item('subclass_prefix').$class.EXT))
{
- require(BASEPATH.'libraries/'.$class.EXT);
- require(APPPATH.'libraries/'.config_item('subclass_prefix').$class.EXT);
+ require_once(BASEPATH.'libraries/'.$class.EXT);
+ require_once(APPPATH.'libraries/'.config_item('subclass_prefix').$class.EXT);
$is_subclass = TRUE;
}
else
{
if (file_exists(APPPATH.'libraries/'.$class.EXT))
{
- require(APPPATH.'libraries/'.$class.EXT);
+ require_once(APPPATH.'libraries/'.$class.EXT);
$is_subclass = FALSE;
}
else
{
- require(BASEPATH.'libraries/'.$class.EXT);
+ require_once(BASEPATH.'libraries/'.$class.EXT);
$is_subclass = FALSE;
}
}
I can't help you much with the testing, but I can help you extend the CI library.
You can create your own MY_Loader class inside /application/libraries/MY_Loader.php.
<?php
class MY_Loader extends CI_Loader {
function view($view, $vars = array(), $return = FALSE) {
echo 'My custom code goes here';
}
}
CodeIgniter will see this automatically. Just put in the functions you want to replace in the original library. Everything else will use the original.
For more info check out the CI manual page for creating core system classes.
I'm impressed by the code you are trying to use.
So now I'm wondering how the 'Hooks' class of CodeIgniter could be of any help to your problem?
http://codeigniter.com/user_guide/general/hooks.html
Kind regards,
Rein Groot
The controller should not contain domain logic, so unit tests make no sense here.
Instead I would test the controllers and views with acceptance tests.