404 View / Handle Exceptions
17 views
Skip to first unread message
Chris Boden
Mar 28, 2011, 11:04:14 AM3/28/11
to Alloy
How do I create a 404 view or an error page to globally handle
exceptions?
Bad routes, bad method calls, bad actions, bad formats, Controller
response with diff status code, uncaught exception, etc. I'd like a
pretty error page for my site. :)
exceptions?
Bad routes, bad method calls, bad actions, bad formats, Controller
response with diff status code, uncaught exception, etc. I'd like a
pretty error page for my site. :)
Vance Lucas
Mar 28, 2011, 11:34:15 AM3/28/11
to allo...@googlegroups.com
Create a plugin that adds a filter on the 'dispatch_exception' filter. The argument passed in is the exception. Return whatever other content you want. As long as whatever you return is not the exception, it will be displayed.
Code:
-------------
<?php
namespace Plugin\ExceptionHandler;
use Alloy;
/**
* ExceptionHandler Plugin
*/
class Plugin
{
/**
* Initialize plguin
*/
public function __construct(Alloy\Kernel $kernel)
{
// Add 'errorDisplay' method as callback for 'dispatch_exception' filter
$kernel->events()->addFilter('dispatch_exception', 'error_display', array($this, 'errorDisplay'));
}
/**
* Wrap new layout view around result content
*/
public function errorDisplay($content)
{
$kernel = \Kernel();
$request = $kernel->request();
// Render direct layout
$content = new \Alloy\View\Template('error');
$content->path($kernel->config('path.layouts'))
->format($request->format)
->set(array('content' => "Oh noes! Something terrible happened!"));
// Could also perform a custom dispatch...
// $content = $kernel->dispatch('Error', 'showError');
return $content;
}
}
-------------
Chris Boden
Mar 28, 2011, 12:10:28 PM3/28/11
to Alloy
Thanks Vance. I'm in the process of adding this to my application.
I'm using the dispatchRequest method to get the view. The parameters
weren't being passed into the Request object though. I've opened a
pull request to fix this here: https://github.com/alloyphp/alloy/pull/9
I have a few more issues/questions/suggestions:
1) May I suggest the notion that the functionality I'm trying to
achieve in my application should be a core feature of Alloy (and
simpler).
2) This did not cover all errors. A bad template call was not caught
by this.
3) Would you be able to document on the Alloy site all the available/
default hooks for filters?
Thanks.
> // @seehttp://alloyframework.org/manual/dispatching/
I'm using the dispatchRequest method to get the view. The parameters
weren't being passed into the Request object though. I've opened a
pull request to fix this here: https://github.com/alloyphp/alloy/pull/9
I have a few more issues/questions/suggestions:
1) May I suggest the notion that the functionality I'm trying to
achieve in my application should be a core feature of Alloy (and
simpler).
2) This did not cover all errors. A bad template call was not caught
by this.
3) Would you be able to document on the Alloy site all the available/
default hooks for filters?
Thanks.
> // $content = $kernel->dispatch('Error', 'showError');
>
> return $content;
> }}
>
> -------------
>
> --
> Vance Lucashttp://vancelucas.com
>
> return $content;
> }}
>
> -------------
>
> --
Vance Lucas
Mar 28, 2011, 12:20:55 PM3/28/11
to allo...@googlegroups.com
As it stands now, the Request object will be passed as the first parameter, and other parameters are passed afterwards. You mean what you want is for all the parameters to be merged onto the Request object and for it to be the only parameter?
Chris Boden
Mar 28, 2011, 12:23:03 PM3/28/11
to Alloy
For dispatchRequest, yes. If my understanding of the functionality is
correct, dispatch calls an internal method (with multiple parameters
passed) whereas dispatchRequest mimics an external (HTTP/RESTful)
request where all parameters would be passed within the request
object.
On Mar 28, 12:20 pm, Vance Lucas <va...@vancelucas.com> wrote:
> As it stands now, the Request object will be passed as the first parameter,
> and other parameters are passed afterwards. You mean what you want is for
> all the parameters to be merged onto the Request object and for it to be the
> only parameter?
>
> --
> Vance Lucashttp://vancelucas.com
correct, dispatch calls an internal method (with multiple parameters
passed) whereas dispatchRequest mimics an external (HTTP/RESTful)
request where all parameters would be passed within the request
object.
On Mar 28, 12:20 pm, Vance Lucas <va...@vancelucas.com> wrote:
> As it stands now, the Request object will be passed as the first parameter,
> and other parameters are passed afterwards. You mean what you want is for
> all the parameters to be merged onto the Request object and for it to be the
> only parameter?
>
> --
Vance Lucas
Mar 28, 2011, 12:25:02 PM3/28/11
to allo...@googlegroups.com
Yes, and I agree that does make more sense. Allowing multiple parameters would in effect break the HTTP interface if they are not optional. I will make the change, but using the "setParams" method on the Request object that takes and array instead of using the foreach loop.
--
Vance Lucas
http://vancelucas.com
Chris Boden
Mar 28, 2011, 12:27:20 PM3/28/11
to Alloy
Good stuff. I see setParams now that you mention it. My apologies,
I'm still not 100% familiar with everything Alloy has to offer.
On Mar 28, 12:25 pm, Vance Lucas <va...@vancelucas.com> wrote:
> Yes, and I agree that does make more sense. Allowing multiple parameters
> would in effect break the HTTP interface if they are not optional. I will
> make the change, but using the "setParams" method on the Request object that
> takes and array instead of using the foreach loop.
>
> --
I'm still not 100% familiar with everything Alloy has to offer.
On Mar 28, 12:25 pm, Vance Lucas <va...@vancelucas.com> wrote:
> Yes, and I agree that does make more sense. Allowing multiple parameters
> would in effect break the HTTP interface if they are not optional. I will
> make the change, but using the "setParams" method on the Request object that
> takes and array instead of using the foreach loop.
>
> --
Vance Lucas
Mar 28, 2011, 12:33:37 PM3/28/11
to allo...@googlegroups.com
Vance Lucas
Mar 28, 2011, 12:55:35 PM3/28/11
to allo...@googlegroups.com
I just realized a problem with this -- If the params passed are just in a numerically-indexed array, this may cause some issues. The params have to be in key/value pairs in order for this to work correctly, which enforces a few more constraints that have to be checked.
On Mon, Mar 28, 2011 at 11:33 AM, Vance Lucas <va...@vancelucas.com> wrote:
No problem :)The change has been made:
--
Vance Lucas
Chris Boden
Mar 28, 2011, 1:06:13 PM3/28/11
to Alloy
I tested sending an indexed array. No errors, the request parameter
keys showed up a the numbers...what if the user intended to send
numerical indices? (which are allowed in a HTTP request).
I believe the desired approach to this issue is a matter of opinion.
Do you enforce (typecast?) associative indices or let the user
(perhaps) make a passable error? I would lobby leave as-is, but the
decision is up to you (Vance).
On Mar 28, 12:55 pm, Vance Lucas <va...@vancelucas.com> wrote:
> I just realized a problem with this -- If the params passed are just in a
> numerically-indexed array, this may cause some issues. The params have to be
> in key/value pairs in order for this to work correctly, which enforces a few
> more constraints that have to be checked.
>
> --
> Vance Lucashttp://vancelucas.com
>
>
>
keys showed up a the numbers...what if the user intended to send
numerical indices? (which are allowed in a HTTP request).
I believe the desired approach to this issue is a matter of opinion.
Do you enforce (typecast?) associative indices or let the user
(perhaps) make a passable error? I would lobby leave as-is, but the
decision is up to you (Vance).
On Mar 28, 12:55 pm, Vance Lucas <va...@vancelucas.com> wrote:
> I just realized a problem with this -- If the params passed are just in a
> numerically-indexed array, this may cause some issues. The params have to be
> in key/value pairs in order for this to work correctly, which enforces a few
> more constraints that have to be checked.
>
> --
>
>
>
> On Mon, Mar 28, 2011 at 11:33 AM, Vance Lucas <va...@vancelucas.com> wrote:
> > No problem :)
>
> > The change has been made:
>
> >https://github.com/alloyphp/alloy/commit/5e19020c148d690ae1f143d1b0b4...
> > No problem :)
>
> > The change has been made:
>
Vance Lucas
Mar 28, 2011, 2:23:01 PM3/28/11
to allo...@googlegroups.com
If it works, I think it would be best to leave as-is. Thanks for checking it out.
Chris Boden
Apr 1, 2011, 1:39:05 PM4/1/11
to Alloy
As per one of my issues I was still having above (an Exception trace
being displayed instead of being caught by the ErrorHandler Plugin) -
I've committed a bug fix for your review:
https://github.com/cboden/alloy/commit/9696090f884afa9b1a419028e36438ea2fcd5e6c
On Mar 28, 2:23 pm, Vance Lucas <va...@vancelucas.com> wrote:
> If it works, I think it would be best to leave as-is. Thanks for checking it
> out.
>
> --
being displayed instead of being caught by the ErrorHandler Plugin) -
I've committed a bug fix for your review:
https://github.com/cboden/alloy/commit/9696090f884afa9b1a419028e36438ea2fcd5e6c
On Mar 28, 2:23 pm, Vance Lucas <va...@vancelucas.com> wrote:
> If it works, I think it would be best to leave as-is. Thanks for checking it
> out.
>
> --
Vance Lucas
Apr 6, 2011, 3:02:29 PM4/6/11
to allo...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages