Zend Framework and switching view script paths - zend-framework

I have a problem. Basically, depending on whether a user goes to /es or /br or /cn etc on our website, we have different language template files. So far, we were using a custom templating engine to make this work, but are making a switch over to ZF. I can't seem to figure out how to get ZF to look for a view script in say cn/about-us if the language varuable is cn.
I can't (don't want to) use Zend_Translate for this because we have way too many translated template files and it's just not feasible using Zend_Translate for bazillion different files with multi-paragraphs of Chinese/Korean/Japanese, forgetting for a second that I don't speak those languages.
Can anybody help me?

You can write a controller plugin and use it's routeStartup() method to alter Zend_View settings (path to where your view scripts are located) and change the request uri before routing starts.
class My_Controller_Plugin_LanguageSwitcher extends Zend_Controller_Plugin_Abstract
{
public function routeStartup(Zend_Controller_Request_Abstract $request)
{
// examine the $_SERVER['REQUEST_URI'] and look for your language identifier
// fetch the View and set appropriate view scripts path using setScriptPath() method
// strip the language identifier from your REQUEST_URI
// change the request uri using $request->setRequestUri('your-new-uri-without-the-language- identifier');
}
}

Related

TYPO3 extbase create url in repository (not controller)

There are good tutorials on how to create URL's in the controllers like this one. Examples are:
$this->uriBuilder->reset()->setTargetPageUid($page_uid)->setCreateAbsoluteUri(TRUE)->build();
$this->controllerContext->getUriBuilder()->reset()->setTargetPageUid($page_uid)->setArguments(array('person'=>$person->getUid())->buildFrontendUri();
In works from the controller. But I cannot do the same work in a repository. Error log say that reset() in first example and getUriBuilder in second example is called on a non-object when done from a repository.
Any clue on how to get past that?
First of all, you shouldn't do this. For creating URIs in Extbase, you need access to the current controller context, because there are several factors that go into creating an URI (currently called controller action, current host name, selected language, ...). If you would create URIs within your repository (i.e. your data access layer), you would generate a dependency to the HTTP routing layer of the Extbase framework. This is undesirable from an architectural point of view, because it can be argued that it violates separation of concerns and creates a messy cross-dependency.
That being said, if you still want to do this (instead of generating URIs in your controller, or -- better yet -- using a Fluid viewhelper): all you need for building URIs is an instance of the UriBuilder class. Nothing's stopping you from simply passing the controller's UriBuilder instance into the repository, for example as a parameter:
public function fooAction() {
$records = $this->myRepository->findRecordsWithUri($this->uriBuilder);
}
Within your repository function, then simply use the passed UriBuilder instance, just as you would in the controller.

Migrate custom Facebook util library to Yii framework

I have a facebook app developed in plain PHP, I'm migrating the app to YII framework.
The thing is that I use a class call "utilsFacebook" where I have the object facebook(of the fb sdk) and all the methods that I need to get data from facebook, getUserId, getUserFriendList, etc.
I don't know how to handle all the operations that I do in utilsFacebook with Yii.
Create a controller with the functions of utilsFacebook is the correct think to do?
Every time that I instance the controller would create a new Facebook object, Should I store that object in a SESSION to get a better performance or is a bad idea?
Q. Create a controller with the functions of utilsFacebook is the correct think to do?
Having done a facebook app using yii as the framework, i would recommend you to make this library either a component, or an extension.
But definitely don't put these functions in the controller directly. Whenever a controller needs them call the functions using your custom facebook util class.
Components can be put in the folder: projectrootfolder/protected/components
Extensions can be put in the folder: projectrootfolder/protected/extensions
If you don't believe that either of these make semantic sense, you can always create a new folder within protected, say utils and put the class there. However i think extensions is the best way to go.
Q. Should I store that object in a SESSION to get a better performance or is a bad idea?
I don't think it's necessary to store the object in a session, because there will be no visible performance gain. Further you'll complicate your code unnecessarily.
What i had done was, created an app level component and used this component throughout the app, in any controller.
Example:
In your application's config, protected/config/main.php :
'components'=>array(
'fbHelper'=>array( // gave the component this name
'class'=>'ext.utils.FacebookHelper', // had stored the helper class in extensions/utils folder
'parameter1'='somevalue',
// more parameters
),
// standard yii app components
),
This will allow you to use the component like this: Yii::app()->fbHelper->getFriends();
Take a look at the facebook-opengraph extension, which could help you, on the way.

How to get request properties in routeStartup plugin method?

I'm developing a multilanguage application, and use routes with translated segments. For multilingual support I created special Multilingual plugin.
To use translated segments I need set translator for Zend_Controller_Router_Route before routes init. So only possible place for this in my plugin is routeStartup method, but there is one problem here - for determine right locale I need to use properties of request (Zend_Controller_Request_Abstract), like module, controller and action names, but they are not defined yet here in routeStartup method. They are already defined, for example, in routeShutdown - but I can't set translator for route there, because it have to be done before routes init.
So what can I do:
can I get request properties somehow in routeStartup
or can I re-setup translator later in routeShutdown
P.S: there is a question with exactly the same problem Zend_Controller_Router_Route: Could not find a translator, but proposed answers is not the option for me, because I can't just retrieve language code from url with Regex, I have much more complicated code to define right language code.
Thanks.
What about putting your code in preDispatch? That's what I personally do when I need to check if the person is logged in. Maybe you can move your code there too?

layout initialisation peculiarity in Zend Framework

I've noticed something interesting about Zend Framework's bootstrap. I created a new project and then used
zf enable layout
to enable the layout engine. It worked out of the box, woo!
But then I tried creating a function called _initLayout in the bootstrap to set some options. Interestingly, this seems to disable the layout again, even if the function body is actually empty. No errors are thrown, but the layout script is not used anymore (exception being the case when I actually set the options again and manually call Zend_Layout::startMvc()).
Renaming the function to anything else, like _initFoo makes the layout work again.
So, my question is: is this a function name that is somehow recognised by Zend Framework and extra actions are applied to it, such as cancelling the layout config from application.ini? Are there other cases where I should avoid certain _init* function names in the bootstrap?
The main purpose of the Bootstrap is to setup resources that the application uses. These can either be setup by lines in the config file (resources.resourcename.foo) or by methods in the bootstrap class (_initResourceName()). I assume zf enable layout has added some resources.layout.* lines to the application.ini. By adding an _initLayout method to the bootstrap, ZF will use this to setup the layout resource instead of the configuration lines.
Are there other cases where I should avoid certain _init* function names in the bootstrap?
The resource plugins are detailed in the manual: http://framework.zend.com/manual/en/zend.application.available-resources.html, _init<resourcename>() will always override any corresponding lines in the config.

Zend Framework: Can you do ACL without the plugins directory?

I am having trouble understanding the rules to ACL in ZF and the docs aren't clear. I am using a common Zend library for all websites. So far no problem but now every demo or example says that you should place the ACL class (acl.php) in the libraries directory as a plugin. Zend/Library/My/Controller/Plugin/.
I don't want to do this because it defeats the purpose for sharing a common framework directory.
Has anyone done or have any ideas about how to accomplish ACL using individual acl.php class files for each website/web application?
Thanks
You don't have to place the acl.php in the libraries directory as a plugin. The autoloader will load the class just fine, the trick to Zend_Acl is just priming an instance of the class with your roles and resources.
It's been a little while since I touched Zend Framwork but I'll try to steer you in the right direction.
In your bootstrap, create the Zend_Acl object
$acl = new Zend_Acl();
//see documentation on how to add roles and resources
Now create a Plugin folder inside your Controller directory, this will allow you authenticate with your acl.
Inside there create new class that extends Zend_Controller_Plugin_Abstract give it the correct class name to be picked up by the autoloader.
Store the acl you create in the registry and in your plugin override the preDispatch method, from here you have access to the request and the acl (from the zend registry) you can validate as needed. (Some people have controller/action as resources others models. It's quite freeform.
Register your plugin with the front controller.
$frontController->registerPlugin(new My_Controller_Plugin_Acl());
This is probably what the other tutorials are suggesting (or variants of this), it can just be a little confusing sometimes.
You should never add files to your Zend library directory - do you have any links to tutorials recommending this? The files should either go in the library directory under your application's namespace, giving you a structure like:
application/
library/
Zend/
(ZF files)
Foo/
Controller/
Plugin/
...
or in application/plugins, application/controller/helpers or somewhere else depending on the approach you are taking.
Edit: it sounds like a controller plugin is what the tutorial is recommending, in which case you'll want a class like Yourapp_Plugin_Acl (replace 'Yourapp' with your app's namespace) which would live at application/plugins/Acl.php.
Ultimately, you can place it anywhere you want as long as your autoloader is sufficiently configured to find it. And precisely how you use it depends upon what resources and privileges you are trying to protect.
But think you are confusing instantiating your ACL and querying your ACL.
You will most likely instantiate/populate your ACL object during bootstrap and store it in the Bootstrap registry or in the Zend_Registry singleton.
If your resources are controllers and your privileges are actions, then it is common to intercept the dispatch cycle with a preDispatch() plugin that queries your ACL object.
So, we are really looking at two different classes/objects:
One is the ACL itself, extending Zend_Acl. This one could be named Application_Model_Acl and placed in the file application/models/Acl.php.
The other is the front controller plugin. This one could be named Application_Plugin_Acl and stored in the file application/plugins/Acl.php
[Note that both of these presume that we are using an application namespace Application. Also, note that both of these are project-specific.]
Of course, the plugin as described needs to be given the ACL object in order to do its job, so your Bootstrap might have a method like this:
protected _initAclPlugin()
{
$acl = new Application_Model_Acl();
$plugin = new Application_Plugin_Acl($acl);
Zend_Controller_Front::getInstance()->registerPlugin($plugin);
}
But remember, this is only one way to use your ACL. In some cases, your ACL might not be limited to just controllers/actions. In that case, you might need to pass your ACL object to other models/services that query it, as well. In that case, you might have a separate method in your Bootstrap to create your ACL object and store it in the Bootstrap registry. Then your controllers - or even a dependency injection system - can grab it from there and pass it through to whatever downstream models/services might need it.
[You know, looking at my answer, it's not really different from that of #linead. Same idea, different words, but he totally got in first.]