[fw-general] Append 'default' module name to routes, how to?
Hey,
I change the default routes, I append the region of the current locale
to each one using this code:
getPluginResource( "frontcontroller"
)->getFrontController();
/* @var $router Zend_Controller_Router_Rewrite */
$router = $fc->getRouter();
$routes =
$router->removeDefaultRoutes()->addDefaultRoutes()->getRoutes();
/* @var $locale Zend_Locale */
$locale = $this->getPluginResource( "locale" )->getLocale();
$hook = new Zend_Controller_Router_Route(
":region",
array( "region" => strtolower( $locale->getRegion() ) ),
// resources.locale.default = "es_CO"; resources.locale.force = true
array( "region" => "[a-z]{2}" )
);
foreach ( $routes as $name => $route ) {
$chain = new Zend_Controller_Router_Route_Chain();
$chain->chain( $hook )->chain( $route );
$router->addRoute( $name, $chain );
}
// set global param.
$router->setGlobalParam( "region", strtolower( $locale->getRegion() ) );
// start router resource.
$this->bootstrap( "router" );
}
}
// layouts/scripts/layout.php
echo $this->url( array( "module" => "products", "controller" =>
"index", "action" => "current-offers" ) ); // "/"
When I try to assemble a route using Zend_View_Helper_Url I get:
string(1) "/" if the url is: http://192.168.2.10:8091/ but if I append
the region: http://192.168.2.10:8091/co the helper works: string(33)
"/co/products/index/current-offers"
For 'default' module Zend Framework always remove that part from the
url, so if I have a url like this one:
blah.com/co/users/login/something it tries to match /users/ module,
there's a way to not remove /default/ string from the url?
Thanks for any help, I'm really stuck with this.
--
Juan Felipe Alvarez Saldarriaga
http://www.jfalvarez.com
Re: [fw-general] Error handling in Zend
These explanations are very helpful. Thanks Ralph.
On Thu, Dec 16, 2010 at 6:24 PM, Ralph Schindler
wrote:
> Hey Jeremy,
>
> Ultimately, it all depends on what kind of exceptions are thrown, where
> they are thrown, and how the framework is setup to handle them. There's lot
> of moving parts, and a default application already takes care of them form
> you for the most part.
>
> Out of the box, the Front Controller is set to NOT throw exceptions.
> Instead, it catches any exceptions thrown during dispatch, stores them in
> the response object, and forwards the dispatch loop to the
> ErrorHandler/ErrorController (which is on by default).
>
> Furthermore, while you are in 'development mode' (as setup by your
> index.php, typically by an environment variable), your application will
> instruct the ErrorController to display exceptions, you'll see this line in
> your application.ini:
>
> resources.frontController.params.displayExceptions = 1
>
> which is overriding the default from production which is false.
>
> I would suggest sticking with the initial project structure and default
> values in all honesty. The setup is quite good, and very informative when
> there are errors occurring.
>
> So lets look at where exceptions are thrown:
>
> [index.php is hit]
>
> $application is created.
>
> $application->bootstrap() is run.
>
>* exceptions can be thrown here form any resource that
> could not be setup either by configuration (resource.* values)
> or by Bootstrap::_init*() methods. Either way, you can't trust
> you have any part of your application setup, in this case, this
> is beyond a 500 error. These types of exceptions should never
> be thrown in production anyway. If you are getting exceptions
> from bootstrapping, you need to take care of the problem sooner.
>
> $application->run() is called.
>
>* This effectively is Zend_Controller_Front::getInstance()->run();
> For all intents and purposes, any exception thrown here is a 500
> or 404 error, and generally can be handled by ErrorController.
>
>* The only exceptions that make it hard to display a full page
> would be exceptions thrown FROM the ErrorController, or exceptions
> throw FROM the Layout. As you can see, if neither of those
> are in good working order, it's hard to use them to build a page.
>
> If you want to use a try/catch block in your index.php, I would use it only
> on the ->bootstrap() call of the $application, not run() as nothing will be
> emitted. If you insist on throwing exceptions and catching them in the
> index.php, add this value to you application.ini:
>
> resources.frontcontroller.throwExceptions = 1
>
> Hope all that helps,
> Ralph Schindler
>
>
> On 12/15/10 3:43 PM, jalexander3 wrote:
>
>>
>> Hello,
>>
>> I have read about the ErrorController that comes standard with the
>> framework. It seems to only handle certain errors pertaining to missing
>> MVC
>> components--that's fine, I can use that. However, for my purposes I think
>> I
>> need a better understanding of URL rewriting and how the framework works
>> in
>> general.
>>
>> Anyway, here is what I have done in terms of error handling. It's pretty
>> simplistic.
>>
>> My application entry point is wrapped in a try-catch. When an exception
>> pops
>> anywhere in the application, I run a couple of procedures that then send
>> an
>> email and log the message, etc.
>>
>> /* Wrap the entire application in an error handler*/
>> try
>> {
>>$application->bootstrap()
>>->run();
>> }
>> catch (Exception $e)
>> {
>>require_once 'ErrorHandler.php';
>>HandleException($e);
>> }
>>
>> What I really want to do is just pop a jquery dialog box on the page that
>> pops the error (or the previous page if there is something like a 404
>> error). In order to do this I am trying the following:
>>
>> catch (Exception $e)
>> {
>>//require_once 'ErrorHandler.php';
>>//HandleException($e);
>>
>>/*
>>Get the current layout and relocate to it,
>>passing a flag to display the error dialog
>>*/
>>
>>
>> $currentLayout=$application->getBootstrap()->getResource('layout')->getLayoutPath();
>>header('Location: ' . $currentLayout . '?action=error');
>> }
>>
>> The problem is, I don't understand enough about what is going on behind
>> the
>> scenes. $currentLayout points to the layouts directory. The querystring is
>> lost as "http://localhost/TAW/application/layouts?action=error"; then
>> points
>> back to a valid page.
>>
>> At the end of the day, it doesn't make sense to point back to a "valid"
>> page...I would probably point to an "error" page that utilizes a defined
>> layout. But in any case, I still need to maintain that querystring.
>>
>> Does anyone have any thoughts about this entire process? Some best
>> practices? Or more specifically, how to resolve the issue I am having
>> concerning the qu
Re: [fw-general] Error handling in Zend
Hey Jeremy,
Ultimately, it all depends on what kind of exceptions are thrown, where
they are thrown, and how the framework is setup to handle them. There's
lot of moving parts, and a default application already takes care of
them form you for the most part.
Out of the box, the Front Controller is set to NOT throw exceptions.
Instead, it catches any exceptions thrown during dispatch, stores them
in the response object, and forwards the dispatch loop to the
ErrorHandler/ErrorController (which is on by default).
Furthermore, while you are in 'development mode' (as setup by your
index.php, typically by an environment variable), your application will
instruct the ErrorController to display exceptions, you'll see this line
in your application.ini:
resources.frontController.params.displayExceptions = 1
which is overriding the default from production which is false.
I would suggest sticking with the initial project structure and default
values in all honesty. The setup is quite good, and very informative
when there are errors occurring.
So lets look at where exceptions are thrown:
[index.php is hit]
$application is created.
$application->bootstrap() is run.
* exceptions can be thrown here form any resource that
could not be setup either by configuration (resource.* values)
or by Bootstrap::_init*() methods. Either way, you can't trust
you have any part of your application setup, in this case, this
is beyond a 500 error. These types of exceptions should never
be thrown in production anyway. If you are getting exceptions
from bootstrapping, you need to take care of the problem sooner.
$application->run() is called.
* This effectively is Zend_Controller_Front::getInstance()->run();
For all intents and purposes, any exception thrown here is a 500
or 404 error, and generally can be handled by ErrorController.
* The only exceptions that make it hard to display a full page
would be exceptions thrown FROM the ErrorController, or exceptions
throw FROM the Layout. As you can see, if neither of those
are in good working order, it's hard to use them to build a page.
If you want to use a try/catch block in your index.php, I would use it
only on the ->bootstrap() call of the $application, not run() as nothing
will be emitted. If you insist on throwing exceptions and catching them
in the index.php, add this value to you application.ini:
resources.frontcontroller.throwExceptions = 1
Hope all that helps,
Ralph Schindler
On 12/15/10 3:43 PM, jalexander3 wrote:
Hello,
I have read about the ErrorController that comes standard with the
framework. It seems to only handle certain errors pertaining to missing MVC
components--that's fine, I can use that. However, for my purposes I think I
need a better understanding of URL rewriting and how the framework works in
general.
Anyway, here is what I have done in terms of error handling. It's pretty
simplistic.
My application entry point is wrapped in a try-catch. When an exception pops
anywhere in the application, I run a couple of procedures that then send an
email and log the message, etc.
/* Wrap the entire application in an error handler*/
try
{
$application->bootstrap()
->run();
}
catch (Exception $e)
{
require_once 'ErrorHandler.php';
HandleException($e);
}
What I really want to do is just pop a jquery dialog box on the page that
pops the error (or the previous page if there is something like a 404
error). In order to do this I am trying the following:
catch (Exception $e)
{
//require_once 'ErrorHandler.php';
//HandleException($e);
/*
Get the current layout and relocate to it,
passing a flag to display the error dialog
*/
$currentLayout=$application->getBootstrap()->getResource('layout')->getLayoutPath();
header('Location: ' . $currentLayout . '?action=error');
}
The problem is, I don't understand enough about what is going on behind the
scenes. $currentLayout points to the layouts directory. The querystring is
lost as "http://localhost/TAW/application/layouts?action=error"; then points
back to a valid page.
At the end of the day, it doesn't make sense to point back to a "valid"
page...I would probably point to an "error" page that utilizes a defined
layout. But in any case, I still need to maintain that querystring.
Does anyone have any thoughts about this entire process? Some best
practices? Or more specifically, how to resolve the issue I am having
concerning the querystring?
Much appreciated!
Jeremy
[fw-general] Error handling in Zend
Hello,
I have read about the ErrorController that comes standard with the
framework. It seems to only handle certain errors pertaining to missing MVC
components--that's fine, I can use that. However, for my purposes I think I
need a better understanding of URL rewriting and how the framework works in
general.
Anyway, here is what I have done in terms of error handling. It's pretty
simplistic.
My application entry point is wrapped in a try-catch. When an exception pops
anywhere in the application, I run a couple of procedures that then send an
email and log the message, etc.
/* Wrap the entire application in an error handler*/
try
{
$application->bootstrap()
->run();
}
catch (Exception $e)
{
require_once 'ErrorHandler.php';
HandleException($e);
}
What I really want to do is just pop a jquery dialog box on the page that
pops the error (or the previous page if there is something like a 404
error). In order to do this I am trying the following:
catch (Exception $e)
{
//require_once 'ErrorHandler.php';
//HandleException($e);
/*
Get the current layout and relocate to it,
passing a flag to display the error dialog
*/
$currentLayout=$application->getBootstrap()->getResource('layout')->getLayoutPath();
header('Location: ' . $currentLayout . '?action=error');
}
The problem is, I don't understand enough about what is going on behind the
scenes. $currentLayout points to the layouts directory. The querystring is
lost as "http://localhost/TAW/application/layouts?action=error"; then points
back to a valid page.
At the end of the day, it doesn't make sense to point back to a "valid"
page...I would probably point to an "error" page that utilizes a defined
layout. But in any case, I still need to maintain that querystring.
Does anyone have any thoughts about this entire process? Some best
practices? Or more specifically, how to resolve the issue I am having
concerning the querystring?
Much appreciated!
Jeremy
--
View this message in context:
http://zend-framework-community.634137.n4.nabble.com/Error-handling-in-Zend-tp3089950p3089950.html
Sent from the Zend Framework mailing list archive at Nabble.com.
