Start IT up

For importing Request Class use following statement
use Symfony\Component\HttpFoundation\Request;

Following statement creates object of class “Request”
$request = Request::createFromGlobals();

// the URI being requested (e.g. /about) minus any query parameters
Every Index of $_SERVER global variable can be accessed using Request object with using get method
so for example to get $_SERVER['PATH_INFO'] using Request Object use following statement.

$request->getPathInfo();

// retrieve GET and POST variables respectively
$request->query->get(‘foo’);
$request->request->get(‘bar’);

// retrieves an instance of UploadedFile identified by foo
$request->files->get(‘foo’);

$request->getMethod(); // GET, POST, PUT, DELETE, HEAD
$request->getLanguages(); // an array of languages the client accepts

List of functions available in Request class can be accessed via following link\

http://api.symfony.com/2.0/Symfony/Component/HttpFoundation/Request.html

1) CodeIgniter is sleek, easy to learn compared to symfony.

2) CodeIgniter project set up time is very less compared to symfony.

3) CodeIgniter works well for something quick and small, symfony hits when it comes for complicated projects.

4) As CodeIgniter does not accept arguments via the command line, you can not call a specific controller or function, a work around should be adopted but it’s not the case with symfony as it provides a concept called task.

5) CodeIgniter does not have any code generators like symfony which completely rocks symfony.

6) Working with fixtures makes life easier in symfony during development phasem, this is missing in codeIgniter again a run  around should be done.

7) Symfony allows to view the queries fired through development environment but codeIgniter has no such option.

Problem: You have a symfony project with 2 applications ‘customers’ and ‘resellers’. You want www.myretail.com to use ‘customer’ application and www.myresellers.com to use ‘resellers’ application.

here customers app is your default ‘frontend’ app with index.php and resellers app has say ‘reseller.php’ and ‘reseller_dev.php’ controller files.

Solution:
Separate the web folder for each domain you want handle.

so customers content is in /project/web folder and resellers content is in /project/web-reseller/ folder. Move your reseller.php to web-reseller folder and rename it to index.php

You will need to create two virtual host for each domain with document root pointing to their respective folders.

Another solution is to have different .htaccess files. In case you do not want to create separate web folder you can create another .htaccess_reseller file in the web/ folder and redirect all request to reseller.php instead of index.php

I mentioned in my previous post how we decouple the translation dictionary completely from the source so that a change in any text does not affect the templates. That has helped us a lot in several large projects.

Another issue which we frequently encountered when multiple people worked on the same project is conflicting and merging of the dictionary files. Since these files have sequential numbers in each <trans-unit> block, if multiple people want to add translations, these suquential numbers almost overlap and have to be rewritten manually while checking in.

So we decided to generate these symfony interface translation dictionary files using a script. So here’s what we do:

•  put the translations in a properties file: Create one properties file for each language. So for English we create “translations.en.properties”. This has translations like:

USERNAME_LABEL=Username
PASSWORD_LABEL=Password

This ensures that even when multiple people add translations to these files (using a source control like CVS or SVN) there are no issues.

• Also put the following file createXML.php in the same i18b folder.   
• Now you can simply call this script from the command prompt to generate the xml dictionary.

php createXML.php > messages.en.xml

That was pretty simple to do. There are some enhancements this requires, like it should by itself generate all translation files based on the properties files available. But thats for when i get more time to work on it.

Symfony provides interface translation using the XLIFF standard. While using the XLIFF standard here is good, it has one pain point. The pain point becomes apparent when the need arises for changing/editing the phrases. If the phrase is used in several templates, you need to search all the templates and change there as well as in the dictionary.

For example, lets say we define a simple label like “Username” in the dictionary and in several templates. The dictionary will look like:

<?xml version="1.0" ?>
<xliff version="1.0">
  <file orginal="global" source-language="en_US"
    datatype="plaintext">
    <body>
      <trans-unit id="1">
        <source>Username</source>
        <target>ユーザー名</target>
      </trans-unit>
    </body>
  </file>
</xliff>

And in all templates that use the label “Username” we will use the following to translate it based on user’s culture:

echo __('Username');

This is good, but lets say down the line we decide to use the label “User Id” instead of “Username”. To do that we need to update all the templates and the dictionary. This becomes cumbersome if you have a large number of templates that reference this label. If you notice, the cause of the problem lies in the fact that we have used the actual text itself to identify the i18n phrase within all templates.

To get around this problem, what we did was to use a code to identify the phrase and use that in the template. And we provide a dictionary for each of the supported language. So in this case we create an English and Japanese dictionary both. But what about the source language, you would ask. Well, thats a hack: we ended up providing a non existent ISO code. Based on the comment from Dennis, we use English as the source since translation happens even if source and target languages are same.

So here is what our English and Japanese dictionary look like:

<?xml version="1.0" ?>
<xliff version="1.0">
  <file orginal="global" source-language="en_US"
    datatype="plaintext">
    <body>
      <trans-unit id="1">
        <source>LABEL_USERNAME</source>
        <target>Username</target>
      </trans-unit>
    </body>
  </file>
</xliff>

<?xml version="1.0" ?>
<xliff version="1.0">
  <file orginal="global" source-language="en_US"
    datatype="plaintext">
    <body>
      <trans-unit id="1">
        <source>LABEL_USERNAME</source>
        <target>ユーザー名</target>
      </trans-unit>
    </body>
  </file>
</xliff>

And the phrase in the template looks like:

echo __('LABEL_USERNAME')

So now if you want to change the English version of the phrase, you simply update the dictionary and no need to change the templates.