Re: [fw-general] Front Controller Plugin Problems
Thanks for your help, suffice to say I didn't send it 10 times, I submitted
it just the once...
Matthew Weier O'Phinney-3 wrote:
>
> Sending a given message once to the list will suffice; 10 times is
> overkill...
>
> -- James Hargreaves wrote
> (on Tuesday, 28 July 2009, 05:19 AM -0700):
>>
>>
>> James Hargreaves wrote:
>> >
>> > I keep seeing talk of "modules" on some ZF posts, how does this work
>> and
>> > is this something I could use?
>> >
>> I managed to get this working in the end, by modularising the whole
>> application - ie - I created a default module, plus a module for each
>> language, as suggested here:
>>
>> http://framework.zend.com/manual/en/zend.controller.modular.html
>>
>> I used the addModuleDirectory method:
>>
>> $front->addModuleDirectory('/path/to/application/modules');
>>
>> That seems to work okay. The only problem I have encountered is that I
>> cannot share controllers per se, since the class names for the
>> controllers
>> contain the module name:
>>
>> In this paradigm, the module name serves as a prefix to the controllers
>> it
>> contains. The above example contains three module controllers,
>> 'Blog_IndexController', 'News_IndexController', and
>> 'News_ListController'.
>> Two global controllers, 'IndexController' and 'FooController' are also
>> defined; neither of these will be namespaced. This directory structure
>> will
>> be used for examples in this chapter.
>>
>> To overcome this I created various abstract super-controllers and extend
>> these in each module - eg:
>>
>> include APPLICATION_PATH .
>> '/path/to/application/modules/.abstract/IndexController.php';
>>
>> class News_IndexController extends IndexController {
>> // etc etc etc
>> }
>>
>> I am not convinced this is a great way to do things, but it appears to
>> work...
>> --
>> View this message in context:
>> http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698018.html
>> Sent from the Zend Framework mailing list archive at Nabble.com.
>>
>
> --
> Matthew Weier O'Phinney
> Project Lead| matt...@zend.com
> Zend Framework | http://framework.zend.com/
>
>
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24702488.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
Sending a given message once to the list will suffice; 10 times is
overkill...
-- James Hargreaves wrote
(on Tuesday, 28 July 2009, 05:19 AM -0700):
>
>
> James Hargreaves wrote:
> >
> > I keep seeing talk of "modules" on some ZF posts, how does this work and
> > is this something I could use?
> >
> I managed to get this working in the end, by modularising the whole
> application - ie - I created a default module, plus a module for each
> language, as suggested here:
>
> http://framework.zend.com/manual/en/zend.controller.modular.html
>
> I used the addModuleDirectory method:
>
> $front->addModuleDirectory('/path/to/application/modules');
>
> That seems to work okay. The only problem I have encountered is that I
> cannot share controllers per se, since the class names for the controllers
> contain the module name:
>
> In this paradigm, the module name serves as a prefix to the controllers it
> contains. The above example contains three module controllers,
> 'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
> Two global controllers, 'IndexController' and 'FooController' are also
> defined; neither of these will be namespaced. This directory structure will
> be used for examples in this chapter.
>
> To overcome this I created various abstract super-controllers and extend
> these in each module - eg:
>
> include APPLICATION_PATH .
> '/path/to/application/modules/.abstract/IndexController.php';
>
> class News_IndexController extends IndexController {
> // etc etc etc
> }
>
> I am not convinced this is a great way to do things, but it appears to
> work...
> --
> View this message in context:
> http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698018.html
> Sent from the Zend Framework mailing list archive at Nabble.com.
>
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698043.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698041.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698036.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698033.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698039.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698030.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698028.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698024.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698021.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698019.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves wrote:
>
> I keep seeing talk of "modules" on some ZF posts, how does this work and
> is this something I could use?
>
I managed to get this working in the end, by modularising the whole
application - ie - I created a default module, plus a module for each
language, as suggested here:
http://framework.zend.com/manual/en/zend.controller.modular.html
I used the addModuleDirectory method:
$front->addModuleDirectory('/path/to/application/modules');
That seems to work okay. The only problem I have encountered is that I
cannot share controllers per se, since the class names for the controllers
contain the module name:
In this paradigm, the module name serves as a prefix to the controllers it
contains. The above example contains three module controllers,
'Blog_IndexController', 'News_IndexController', and 'News_ListController'.
Two global controllers, 'IndexController' and 'FooController' are also
defined; neither of these will be namespaced. This directory structure will
be used for examples in this chapter.
To overcome this I created various abstract super-controllers and extend
these in each module - eg:
include APPLICATION_PATH .
'/path/to/application/modules/.abstract/IndexController.php';
class News_IndexController extends IndexController {
// etc etc etc
}
I am not convinced this is a great way to do things, but it appears to
work...
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24698018.html
Sent from the Zend Framework mailing list archive at Nabble.com.
Re: [fw-general] Front Controller Plugin Problems
Hi Bart
Thanks for getting back to me. Apologies for the delay in my response, I've
been away :)
Bart McLeod wrote:
>
>
> James Hargreaves wrote:
>>
>> Hello
>>
>> I am trying to implement some functionality via a couple of Controller
>> Plugins - my requirements are as follows:
>>
>> 1) load custom configuration and make this information available in the
>> view
>> 2) check the input URL contains a language code and re-route to holding
>> page (where they can select a language) if it does not
>>
>> Obviously these are two completely separate requirements, hence I would
>> like to do this using two completely separate plugins.
>>
>> Anyway, my first question is ... where do I register the plug-in? I am
>> using the Latest Release of ZF. The index.php generated when I created
>> the project does not obviously have anywhere to load my plug-ins. So,
>> instead I have created a new init method in my Bootstrap.php:
>>
>> protected function _initPlugins() {
>> $front = Zend_Controller_Front::getInstance();
>> $front->registerPlugin(new MyPlugin());
>> $front->registerPlugin(new MyOtherPlugin());
>> }
>>
>> Is that the right way to do this? If I register the plug-ins this way
>> will all hooks into the application stack (eg - routeStartup,
>> dispatchLoopStartup, etc) be available to my plug-in?
>>
> Yes, it is the right way to do this, but I don't see why you put it in a
> function. Is this inside your bootstrap class? In that case I understand.
>
Yes, this is in my Bootstrap class, so I think this makes sense as you
suggest.
Bart McLeod wrote:
>
>
> James Hargreaves wrote:
>>
>> Okay, so assuming what I have done above is okay, onto plug-in (1).
>>
>> I have a configuration file custom.ini that contains, among other things,
>> a Google Maps API key. I want to make this information available in all
>> views throughout the application, so I would do something like:
>>
>> class MyPlugin extends Zend_Controller_Plugin_Abstract {
>> public function routeStartup(Zend_Controller_Request_Abstract
>> $request)
>> {
>> $config = new Zend_Config_Ini('/path/to/config.ini', $this->env);
>> $this->view->google_maps_api_key = $config->google_maps_api_key;
>> }
>> }
>>
> I would say Zend_Registry::set('my_config', $config);
>
> and retrieve this whenever you need it as Zend_Registry::get('my_config');
>
Ah, that is what I am doing at the moment. I was just thinking that there
must be an easier way, but perhaps not.
So, is there no way to access the view object when in a plugin? That seems
like a bit of a limitation to the plug-in method if so, I might have to
write a generic controller class to extend if that is the case, as I would
like to set something on the view throughout the application.
Bart McLeod wrote:
>
>
> James Hargreaves wrote:
>>
>> Is that going to work? I am assuming that $this in this context is not
>> actually the Zend_Application, so $this->env will not yield anything
>> useful, likewise setting anything on $this->view is not going to make
>> this attribute available in the view. Is there someway to access the
>> application via $this - eg - $this->application->env.
>>
>> Onto plug-in (2). I don't really have any idea how to implement this, but
>> my initial thoughts are:
>>
> I don't have time to read all this, but I think you should be looking at
> using a custom route.
> $router = $front->getRouter();
> $router->addRoute(-your new route-);
>
> -Bart
>
Thanks, I will take a look at defining a custom route as you suggest.
James Hargreaves wrote:
>
> - http://www.mydomain.com/ should show a holding page, where a language
> can be selected
> - http://www.mydomain.com// (where is a two-character
> language code such as 'en' or 'de') is the home page for the
> language-specific version of the site
> - http://www.mydomain.com//abc/ is a specific page on the
> language-specific site
>
> - the plug-in should check a valid language code is provided in the URL
> and redirect accordingly.
> - I don't want to provide duplicate controllers for each language, so the
> following URLs should use the same controller:
>
> http://www.mydomain.com/en/abc/
> http://www.mydomain.com/de/abc/
>
> In each case the view script should be .phtml, as oppose to the
> default index.phtml, so that the language of the page can be easily
> defined.
>
> The last bit is just thinking outloud. It might be easier to accomplish
> what I want by splitting the views by the language at the top level of the
> hierarchy - eg:
>
> APPLICATION_PATH/views/scripts/en/abc/index.phtml
>
> As oppose to:
>
> APPLICATION_PATH/views/scripts/abc/en.phtml
>
> I don't really mind either way. But I definitely do not want to duplicate
> the controllers.
>
> Anyway, that's what I need to do. Apologies for the lengthy post, but as
> you can see there are quite a few issues I need to address, I think mainly
> because I am new to ZF and still not fully sure how it all hangs to
Re: [fw-general] Front Controller Plugin Problems
James Hargreaves schreef:
Hello
I am trying to implement some functionality via a couple of Controller
Plugins - my requirements are as follows:
1) load custom configuration and make this information available in the view
2) check the input URL contains a language code and re-route to holding page
(where they can select a language) if it does not
Obviously these are two completely separate requirements, hence I would like
to do this using two completely separate plugins.
Anyway, my first question is ... where do I register the plug-in? I am using
the Latest Release of ZF. The index.php generated when I created the project
does not obviously have anywhere to load my plug-ins. So, instead I have
created a new init method in my Bootstrap.php:
protected function _initPlugins() {
$front = Zend_Controller_Front::getInstance();
$front->registerPlugin(new MyPlugin());
$front->registerPlugin(new MyOtherPlugin());
}
Is that the right way to do this? If I register the plug-ins this way will
all hooks into the application stack (eg - routeStartup,
dispatchLoopStartup, etc) be available to my plug-in?
Yes, it is the right way to do this, but I don't see why you put it in a
function. Is this inside your bootstrap class? In that case I understand.
Okay, so assuming what I have done above is okay, onto plug-in (1).
I have a configuration file custom.ini that contains, among other things, a
Google Maps API key. I want to make this information available in all views
throughout the application, so I would do something like:
class MyPlugin extends Zend_Controller_Plugin_Abstract {
public function routeStartup(Zend_Controller_Request_Abstract $request)
{
$config = new Zend_Config_Ini('/path/to/config.ini', $this->env);
$this->view->google_maps_api_key = $config->google_maps_api_key;
}
}
I would say Zend_Registry::set('my_config', $config);
and retrieve this whenever you need it as Zend_Registry::get('my_config');
Is that going to work? I am assuming that $this in this context is not
actually the Zend_Application, so $this->env will not yield anything useful,
likewise setting anything on $this->view is not going to make this attribute
available in the view. Is there someway to access the application via $this
- eg - $this->application->env.
Onto plug-in (2). I don't really have any idea how to implement this, but my
initial thoughts are:
I don't have time to read all this, but I think you should be looking at
using a custom route.
$router = $front->getRouter();
$router->addRoute(-your new route-);
-Bart
- http://www.mydomain.com/ should show a holding page, where a language can
be selected
- http://www.mydomain.com// (where is a two-character language
code such as 'en' or 'de') is the home page for the language-specific
version of the site
- http://www.mydomain.com//abc/ is a specific page on the
language-specific site
- the plug-in should check a valid language code is provided in the URL and
redirect accordingly.
- I don't want to provide duplicate controllers for each language, so the
following URLs should use the same controller:
http://www.mydomain.com/en/abc/
http://www.mydomain.com/de/abc/
In each case the view script should be .phtml, as oppose to the
default index.phtml, so that the language of the page can be easily defined.
The last bit is just thinking outloud. It might be easier to accomplish what
I want by splitting the views by the language at the top level of the
hierarchy - eg:
APPLICATION_PATH/views/scripts/en/abc/index.phtml
As oppose to:
APPLICATION_PATH/views/scripts/abc/en.phtml
I don't really mind either way. But I definitely do not want to duplicate
the controllers.
Anyway, that's what I need to do. Apologies for the lengthy post, but as you
can see there are quite a few issues I need to address, I think mainly
because I am new to ZF and still not fully sure how it all hangs together.
Any help would be appreciated :)
Thanks
Jay
[fw-general] Front Controller Plugin Problems
Hello
I am trying to implement some functionality via a couple of Controller
Plugins - my requirements are as follows:
1) load custom configuration and make this information available in the view
2) check the input URL contains a language code and re-route to holding page
(where they can select a language) if it does not
Obviously these are two completely separate requirements, hence I would like
to do this using two completely separate plugins.
Anyway, my first question is ... where do I register the plug-in? I am using
the Latest Release of ZF. The index.php generated when I created the project
does not obviously have anywhere to load my plug-ins. So, instead I have
created a new init method in my Bootstrap.php:
protected function _initPlugins() {
$front = Zend_Controller_Front::getInstance();
$front->registerPlugin(new MyPlugin());
$front->registerPlugin(new MyOtherPlugin());
}
Is that the right way to do this? If I register the plug-ins this way will
all hooks into the application stack (eg - routeStartup,
dispatchLoopStartup, etc) be available to my plug-in?
Okay, so assuming what I have done above is okay, onto plug-in (1).
I have a configuration file custom.ini that contains, among other things, a
Google Maps API key. I want to make this information available in all views
throughout the application, so I would do something like:
class MyPlugin extends Zend_Controller_Plugin_Abstract {
public function routeStartup(Zend_Controller_Request_Abstract $request)
{
$config = new Zend_Config_Ini('/path/to/config.ini', $this->env);
$this->view->google_maps_api_key = $config->google_maps_api_key;
}
}
Is that going to work? I am assuming that $this in this context is not
actually the Zend_Application, so $this->env will not yield anything useful,
likewise setting anything on $this->view is not going to make this attribute
available in the view. Is there someway to access the application via $this
- eg - $this->application->env.
Onto plug-in (2). I don't really have any idea how to implement this, but my
initial thoughts are:
- http://www.mydomain.com/ should show a holding page, where a language can
be selected
- http://www.mydomain.com// (where is a two-character language
code such as 'en' or 'de') is the home page for the language-specific
version of the site
- http://www.mydomain.com//abc/ is a specific page on the
language-specific site
- the plug-in should check a valid language code is provided in the URL and
redirect accordingly.
- I don't want to provide duplicate controllers for each language, so the
following URLs should use the same controller:
http://www.mydomain.com/en/abc/
http://www.mydomain.com/de/abc/
In each case the view script should be .phtml, as oppose to the
default index.phtml, so that the language of the page can be easily defined.
The last bit is just thinking outloud. It might be easier to accomplish what
I want by splitting the views by the language at the top level of the
hierarchy - eg:
APPLICATION_PATH/views/scripts/en/abc/index.phtml
As oppose to:
APPLICATION_PATH/views/scripts/abc/en.phtml
I don't really mind either way. But I definitely do not want to duplicate
the controllers.
Anyway, that's what I need to do. Apologies for the lengthy post, but as you
can see there are quite a few issues I need to address, I think mainly
because I am new to ZF and still not fully sure how it all hangs together.
Any help would be appreciated :)
Thanks
Jay
--
View this message in context:
http://www.nabble.com/Front-Controller-Plugin-Problems-tp24642509p24642509.html
Sent from the Zend Framework mailing list archive at Nabble.com.
