Diferentes JS em cada ambiente do Symfony.

Quem estiver querendo colocar um site em produção vai provavelmente se deparar com a necessidade de "minificar" os arquivos de javascript. Porém é interessante manter os arquivos não minificados no projeto também para ficar mais fácil de editar e debugar. Porém o view.yml do symfony não permite configurações sensíveis ao ambiente. Assim achei uma solução bem simples em http://shout.setfive.com/2009/06/09/loading-different-javascript-css-files-in-different-environments/ que é a seguinte:

1 - Crie as configurações (um array) para cada ambiente no app.yml com o nome de "javascript_files".

2 - no view.yml faça referência a estas configurações usando:

javascripts: [< ? php echo implode(',',sfConfig::get('app_javascript_files');) ? >]  

Depois me disseram que o view.yml está "deprecated", então fiz o seguinte:

Incluí uma partial em todos meus leiautes e nessa parcial usei:

< ?php if(sfConfig::get('sf_debug')): ? >
   < ?php use_javascript('x') ?>
   < ?php use_javascript('y') ?>
   < ?php use_javascript('z') ?>
< ? else: ? >
   < ?php use_javascript('xyz.min.js') ?>
< ? endif; ? >

Usando classes do Zend Framework no Symfony

1 - incluir as classes em plugins/Zend/lib

2 - configurar o caminho no settings.yml

# Zend Framework
zend_autoload: on
zend_lib_dir: "%SF_PLUGINS_DIR%/Zend/lib"

3 - inicializar o autoload no frontendConfiguration:

/**
* @package system
* @subpackage configuration
*/
class frontendConfiguration extends sfApplicationConfiguration
{
public function configure()
{

}

public function initialize()
{
parent::initialize();
/**
* Zend Framework Autoloading
*/
if(sfConfig::get('sf_zend_autoload', true) && ($sf_zend_lib_dir = sfConfig::get('sf_zend_lib_dir'))) {
set_include_path($sf_zend_lib_dir.PATH_SEPARATOR.get_include_path());
require_once($sf_zend_lib_dir.DIRECTORY_SEPARATOR.'Zend'.DIRECTORY_SEPARATOR .'Loader.php');
spl_autoload_register(array('Zend_Loader', 'loadClass'));
}

/**
* DOMPdf Autoloading
*/
if(sfConfig::get('sf_dompdf_autoload', true) && ($sf_dompdf_lib_dir = sfConfig::get('sf_dompdf_lib_dir'))) {
set_include_path($sf_dompdf_lib_dir.PATH_SEPARATOR.get_include_path());
// require_once($sf_dompdf_lib_dir.DIRECTORY_SEPARATOR.'dompdf_config.inc.php');
// spl_autoload_register('DOMPDF_autoload');
}
}
}

Criando testes no PHPUnit/Selenium que rodem com o symfony/doctrine/phing/phpunit

Ingredientes

symfony+doctrine: framework de desenvolvimento e ORM
phpunit: para testes unitários
phing: para fazer o build, rodar os testes, gerar a documentação, lavar a roupa, etc...

Problemas a se Vencer:

O phpunit, quando roda pela linha de comando, não carrega as configurações do projeto do symfony.

Alguns testes do selenium precisam de acesso à api do symfony para configurar o ambiente e ter acesso aonde o browser não tem.

Descrição da Solução:

Para isso precisamos carregar as configurações do symfony/docrine. Claro que é bom fazer isto uma vez só para não pesar nos testes. Porém precisamos fazer isto de uma maneira que não prenda muito os testes a um diretório específico e que não seja repetitiva.

O phpunit, quando rodado pelo phing, não considera as suites de teste, rodando todos os testes separadamente. Por isso, o setUp() da suite, que poderia parecer um bom local, na verdade não é pois ele será desconsiderado pelo phing. Escolhemos então o setUp de cada classe teste. Para não repetir o código, criamos uma classe da qual extendemos todos os nossos testes. Assim nossas classes já herdam o setUp. Como o autoload do symfony ainda não foi carregado, precisamos informar para o phpunit o caminho da nossa classe caso ela não esteja no include.

Solução Proposta:


### classe pai

class Sf_PHPUnit_Extensions_SeleniumTestCase extends PHPUnit_Extensions_SeleniumTestCase {
function setUp()
{
if ( SF_APP_NAME != '' )
{
define( 'SF_APP_NAME', 'frontend' );
define( 'SF_ENV', 'test' );
define( 'SF_CONN', 'doctrine' );
// ajuste o caminho abaixo de acordo com o local onde vc por esta classe
require_once(dirname(__FILE__).'/../../../../config/ProjectConfiguration.class.php');
// busca as configurações do projeto
$configuration = ProjectConfiguration::getApplicationConfiguration( SF_APP_NAME , SF_ENV, true);
sfContext::createInstance($configuration);
sfContext::getInstance()->getUser()->initSession('phpunit');
// em alguns contextos as linhas abaixo podem ser úteis, mas não lembro quais agora :)
//$databaseManager = new sfDatabaseManager($configuration);
//$databaseManager->loadConfiguration();
}

$this->setBrowser("firefox");
// "solução de contorno" para definir se o teste está no ambiente de desenv ou homolog.
if(isset($_SERVER[HOMEDRIVE]) && $_SERVER[HOMEDRIVE] == 'C:') {
$this->setBrowserUrl("http://aliaslocal/");
}
else {
// ip ou alias do servidor...
$this->setBrowserUrl("http://10.1.1.234/");
}
}
}

### classe filha


require_once 'PHPUnit/Extensions/SeleniumTestCase.php';
// lembrar que este require é necessário pois o autoload do symfony ainda não foi carregado neste ponto.
require_once dirname(__FILE__).'/../../../plugins/sfUtil/lib/test/SF_PHPUnit_Extensions_SeleniumTestCase.php';

class LoginSeleniumTest extends SF_PHPUnit_Extensions_SeleniumTestCase
{

function setUp() {
// lembrar de chamar o setUp do pai caso precise extender aqui...
parent::setUp();
$this->doSomeMoreSetup();
}
// ...

Conclusão:

Claro que devem existir inúmeras soluções para este problema. Caso você tenha algo a acrescentar ou alguma crítica construtiva, certamente isto vai melhorar ainda mais a nossa proposta.