I am building a multi-lingual application with Zend Framework 2.
Currently, I have every object with a translatable output implement the TranslatorAwareInterface and use the TranslatorAwareTrait. So, I'am injecting a translator instance into every form, input filter and controller object in order to translate form labels, error messages and notifications.
Is this the correct way to do it or is there a different approach which does not require to inject a translator instance into every object having a text needing a translation?
(I know I can translate validation errors by injecting a default translator to AbstractValidator, but I prefer to have my own error messages)
use doctrine module for zf2 as orm and let Doctrine extension gedmo/translatable handle the data translation https://github.com/l3pp4rd/DoctrineExtensions
To get the Translatable feature working, follow this part of the documentation:
https://github.com/l3pp4rd/DoctrineExtensions/blob/master/doc/zendframework2.md#note-you-may-need-to-provide-additional-settings-for-some-of-the-available-listeners
After that run the schema tool to update your database.
Related
I'm trying to teach myself ZF2 in conjunction with Doctrine 2. I've completed both the Album tutorial and Blog Tutorial on Zend's website successfully. Now I'm trying to go back and convert the Blog Tutorial to use Doctrine 2. I believe I've successfully setup my config for doctrine and used DI to get it inside of my controller (WriteController.php) since I am able to dump the contents of it within my action. I don't get any errors so long as I don't do anything with it.
My question is what roll does Doctrine take in the Controller -> Service -> Mapper -> Backend layered structure which was taught in the Blog tutorial? (Reference To what I mean)
Also, I'm assuming Backend is referring to my Models. Is this correct?
Would I just replace any references to /Blog/Model/Post with /Blog/Entity/Blog?
The Doctrine is the Mapper. And maybe we could say also the Service (through EntityRepository). But usually you will create your own Service Layer.
The Backend is not the entities it self. Entities in one way to map the several options of backend. As backend you can understand the several options of Relational Databases (Mysql, SqlServer, Oracle, etc) NoSql Databases (like MongoDB), file system and so on.
I didn't understand your last question. But when I use Doctrine I always create my entities in /MyModule/Entity namespace. While when I use the standart Zend/Db I always create in /MyModule/Model. I do that by standardizing matters.
I have a Symfony2 project and today I'm asked to make it internationalized.
I have several MySQL entities and the new translated contents that I would like to put in a single table containing:
ID | language | content_key | content_translation
Once the _locale is set, I would like to be able to pass this at Entity level, in order to make the Model layer retrieve the content itselves (making a second call to the translation table if that content is one of the translatable one).
I've tried to use Translatable Extension, but since it is a pre-existing database and project, it is not an easy way to pursue.
How can I inject the request (or pass the _locale only) to my Entities?
Thanks a lot,
Andrea
I think you are using Doctrine as ORM with Symfony2?
Then have a look at the Doctrine Extensions. This bundle provides different new behaviors for your entities.
It has also a translatable behavior which is really powerfull.
Integrating the doctrine extensions in Symfony2 is not so complicated.
If you can't use the Doctrine Extensions with your Code/Database, i would try the Doctrine Event Listeners to develop the translatable behavior of your own.
Recently I began to study SF2 but there are some doubts which I'd like to solve:
Let's say that I have a lot (more than 100) of Models which extend one generic model(Entity). Each model has unique functions (rules for parsing content from model source), what is the best way to organize it?
In ZF1 I would create Model/ModelType/ModelName.php file for every model which need customization, in SF2 I'm not sure what kind of entity should I use: One service container which calls entities and call their custom functions (implemented through interface), or maybe one huge Service which has different functions for every single model?
Thanks in advance.
If parsing functions based only on current entity state (use only entity property) it's better to use entity method. Entity aslo can implement some interface, e.g. ParsableInterface.
If paring function need to use another entities it's better to use standalone services handle parsing
I am developing RESTful with php. Currently I have started coding with MVC design pattern. In which the view files are acting as an interface. An interface which isn't showing any graphical UI but it has all the request handling logic.
Now, my question is the way I am coding is correct or there is a better way to create RESTful api in php?
My inspiration is based on JavaEE application model. In which we have Entity classes as model, Java beans as controllers and Remote Interface is the the list of method which gets called from client (kind of a view).
Am I on right track?
A good example for building a RESTful API in a PHP based MVC framework can be found at http://www.chrisdanielson.com/2009/09/02/creating-a-php-rest-api-using-the-zend-framework/.
This example extends a class in Zend Framework called the Zend_Rest_Controller which simplifies this process. You can have a look at the source code to see how they do it and if it gives you an ideas on how to make your own implementation.
To answer your question though, you should have controllers acting as the interface. So if you send a POST request to myapp.com/comment (where comment is the controller), it knows you are trying to add a new comment. If you send a GET request to the same URL, it knows you want all of the comments, and if you send a GET request to myapp.com/comment/4 it knows you want to get the comment with ID 4. Your views should have nothing to do with the internal functionality of your API.
You can use any existing RESTful PHP MVC framework, like Yii or Kohana both are very light and natively support RESTful applications.
For your existing application, MVC model states that all the requests and logic handling should be done by the Controllers not the views. Things are usually done in one of two ways here:
(1) Controller has a special method to respond to each type of requests and acts differently As seen in RubyOnRails (mainly at the end of each controller action)
respond_to do |format|
format.html
format.xml { render :xml => #events}
format.json { render :json => #events}
end
(2) Controller detects the current requested format and changes that entire theme/layout to, say, a JSON theme (All layouts/views receive the same data). This is my current implementation and it goes like:
$format is any of [html,json,xml] (detected from url suffix)
$controller->layout = "$format";
$controller->render($viewFile, $object);
view file in HTML Layout
<div id='model>
<h1><?=$object->title?></h1>
<p><?=$object->description?></p>
</div>
View file in JSON layout
echo json_encode($object);
View file in XML layout
/** Loop and build XML tree */
I did a bunch of webinars on API Facade Design Patterns. Hope you will find the concepts useful irrespective of the underlying technology you use to implement it. Please can find it here
http://youtu.be/n8B-K3iJ7b4
http://youtu.be/MRxTP-rQ-S8
http://youtu.be/aJBhVm4BbCI
Apigility is a Zend Framework 2 based project designed soley for the purpose of creating REST and RPC services.
https://apigility.org/
Out of the box you're given an easy way to get started with MySQL and OAuth2 for authentication.
I'm working on a Symfony 1.4 project with Doctrine 1.x, and functionality that merits using a Doctrie_View (as an interface for native MySQL Views).
As I understand it, the View (as in DB View as opposed to the View in MVC) has to be created wth Doctrine so that Doctrine can maintain the association between the View and the original Model from which it's derived.
In an ideal world, I'd like to have the View created as part of the symfony doctrine:build --db task. The sensible way to do this would be to use the observer pattern and Symfony's Event Dispatcher, however, the list of Built In-Events doesn't seem to offer an event for when the database schema is built.
So, what's the best way to have a Doctrine View created when the schema is built?
Or perhaps, if that's not an option, check if a View doesn't exist and then create it as part of ProjectConfiguration::configureDoctrine()?
doctrine:build-sql
I think you should rather look at the doctrine:build-sql task which builds the sql instructions from the model definition.
If you look at the sfDoctrineBuildSqlTask class you'll notice it's rather simple. It really only calls the doctrine cli. If you want to hook into it you should check the Doctrine events rather than symfony.
migrations
What you could also do is creating your view in doctrine migrations. Whenever you need to change your view you'll create another migration (removing old and creating new view).