Keep-Alive: Fazendo flush antes do término da execução, no controller do Symfony 2

No Symfony (1 e 2), a saída do controlador apenas é enviada após o processamento interno.

Para uma saída constante, em processos demorados, precisamos outra abordagem,

chamando o flush manualmente e seguindo o caminho Keep-Alive.

A necessidade

A CamelSpiderBundle possui um controller que executa a CamelSpider e isto pode demorar um pouco.

É necessário que exista uma saída informativa e uma negociação com o navegador para que não seja interrompida a exibição.

Solução: 

//….

    public function captureAction($id)
    {
        $response = new Response();
        $response->headers->set(‘Content-Encoding’, ‘chunked’);
        $response->headers->set(‘Transfer-Encoding’, ‘chunked’);
        $response->headers->set(‘Content-Type’, ‘text/html’);
        $response->headers->set(‘Connection’, ‘keep-alive’);
        $response->sendHeaders();
        flush();
        ob_flush();
        echo “<html><head><title>Capture</title></head><body><pre>”; 
        $this->get(‘camel_spider.launcher’)->checkUpdates($id);
         echo nnnn<b>Done</b>.”;
        echo “</pre></body></html>”;
        return $response;
    }
//…..
Você pode visualizar o arquivo completo aqui
Algumas informações relevantes:

Customizando as páginas de erro no Symfony 2

Existem várias formas de customizar as páginas de erro no Symfony 2,

mas uma maneira bem simples,

é sobrecarregar a view de erros da Twig,

criando o arquivo app/Resources/TwigBundle/views/Exception/error.html.twig:

https://gist.github.com/1402754

 

Lógico que esta sobrecarga de exibição é feita apenas no ambiente de produção,

e para testar suas alterações você precisa limpar o cache.

./app/console cache:clear –env=prod

 

 

Como acessar as informações do Usuário, no Controller Symfony 2

Se você implementou o login conforme a documentação,
pode utilizar a seguinte forma:

<?php

namespace AcmeDemoBundleController;

class DemoController extends Controller
{
    public function indexAction()
    {
            //seu objeto Token, definido no Provider:
            $this->get(‘security.context’)->getToken();

            //seu objeto Identity, definido no Provider                        
            $this->get(‘security.context’)->getToken()->getUser();     

            //seu método implementado no objeto Identity
            $this->get(‘security.context’)->getToken()->getUser()->getLastName();   

//….

Podcast: Symfony 2 MongoDB

Um papo despretencioso com meu amigo  (Rafael Goulart),
sobre Chaves, Pat & Mat  e NoSQL.

Aproveitei a chegada da minha caneta Stylus e “escrevi” a imagem tema para

esta série de podcasts em modelo Bazar.

Img_0252

 

O livro que o Rafael cita é o 50 Tips and Tricks for MongoDB Developers de  Kristina Chodorow

 

 

E o que você tem para comentar no Podcast: Primeiras impressões sobre Symfony 2  ?

Participe!

Symfony Doctrine Migrations

Fig02

 

Você já colocou seu site para rodar na produção,
mas precisou modificar a estrutura do banco de dados.

E se estas alterações devem ser executadas em 10 sites que utilizam o mesmo aplicativo?

Executar o sql manualmente em cada website?

Não.
Migrations!

A cada alteração no schema, no ambiente DEV:

./symfony doc:generate-migrations-diff
./symfony doctrine:build --all-classes --and-migrate

Quando você finalmente enviar para produção, execute no ambiente Prod:

./symfony doc:migrate --env="prod"

Você pode utilizar também a opção –dry-run

Referências:

http://www.slideshare.net/denderello/symfony-live-2010-using-doctrine-migrations

http://www.slideshare.net/weaverryan/the-art-of-doctrine-migrations