Numa listagem do admin generator criar um link para um módulo e acção diferentes

Criar o método para devolver o link, no modelo que estamos a trabalhar:

public function getArticleLink()
{
  return link_to($this->getArticle()->getTitle(), 'article/edit?id='.$this->getArticleId());
}

No generator.yml colocar a entrada respectiva:

generator:
  class:              sfPropelAdminGenerator
  param:
    model_class:      Comment
    theme:            default

    fields:
      id:             { name: Id }
      article_link:   { name: Article }
      author:         { name: Author }
      date:           { name: Published on }
      content:        { name: Body }

    list:
      display:        [id, article_link, date]
      ... 

Retirado daqui:
http://vit.free.fr/symfony/0.6.3/generator.html

Criar administração com acção SHOW

Em symfony 1.2 com propel pode usar-se este plugin:

http://www.symfony-project.org/plugins/sfPropelAdminGeneratorWithShowPlugin
ou aqui:
http://symplist.net/plugins/sfPropelAdminGeneratorWithShowPlugin

No caso do symfony 1.4 com doctrine, já temos uma opção mais completa, com este plugin:

http://www.symfony-project.org/plugins/sfAdminThemejRollerPlugin

sfGuard credenciais para acesso a módulos

As fixtures abaixo vão gerar:

• 2 grupos de utilizadores (admin e author)
• 2 tipos de permissoes (admin e author)
• 2 utilizadores (admin e author)

sfGuardUser:
  sgu_admin:
    username:       admin
    password:       admin
    is_super_admin: true
  sgu_author:
    username:       author
    password:       author
    is_super_admin: false

sfGuardPermission:
  sgp_admin:
    name:           admin
    description:    Administrator permission
  sgp_author:
    name:           author
    description:    Author permission

sfGuardGroup:
  sgg_admin:
    name:           admin
    description:    Administrator group
  sgg_author:
    name:           author
    description:    Author group

sfGuardGroupPermission:
  sggp_admin:
    sfGuardGroup:       sgg_admin
    sfGuardPermission:  sgp_admin
  sggp_author:
    sfGuardGroup:       sgg_author
    sfGuardPermission:  sgp_author

sfGuardUserGroup:
  sgug_admin:
    sfGuardGroup:       sgg_admin
    sfGuardUser:        sgu_admin
  sgug_author:
    sfGuardGroup:       sgg_author
    sfGuardUser:        sgu_author

Para no backend fazer com que um utilizador do grupo "author" apenas tenha acesso (de leitura e escrita) no módulo "article" deve-se editar o ficheiro
apps/backend/modules/article/config/security.yml:

default:
  is_secure: on
  credentials: [author]

Para todos os restantes módulos temos que restringir o acesso a utilizadores do grupo "admin":
Para garantirmos que os restantes módulos estejam apenas acessíveis para utilizadores do grupo "admin",  temos que editar o ficheiro
apps/backend/config/security.yml:

default:
  is_secure: on
  credentials: [admin]

Se numa vista com acesso geral quisermos filtrar o conteúdo dependendo da credencial, podemos verifica-la assim:

$sf_user->hasCredential('author')

Mais informações sobre sfGuard estão disponíveis aqui e aqui.
Mais informações sobre credentials aqui.

Re-escrever método get duma tabela

Como já não é a primeira vez que me esqueço fica aqui a nota. Neste exemplo vou re-escrever o método getSuperCategory que por default retorna o nome da "SuperCategory" caso exista, ou vazio, caso contrário:

class Category extends BaseCategory
{
  public function getSuperCategory()
  {
    return $this->_get('super_category_id')?Doctrine::getTable('SuperCategory')->find($this->_get('super_category_id')):'<Nenhuma>';
  }
}

Agora quando chamar o getSuperCategory e não existir SuperCategory associada é-me retornado <Nenhuma>

Motor de templating no symfony 2.0?

Pois é, um dos aspectos que, por um lado gostei, mas por outro lado estranhei quando comecei a trabalhar com Symfony, foi o facto de não usar nenhum mecanismo de templates adicional como acontece em muitas frameworks (motores como por exemplo Smarty).

Apesar dos mecanismos de templating tenderem a ser muito simples, o facto é que se trata de uma outra "linguagem" que é necessário aprender, daí ter achado boa ideia poder usar o PHP para fazer os templates.

Agora um dos fundadores/developers do Symfony aborda este tema de uma forma muito interessante explorando as vantagens e desvantagens desta escolha:

http://fabien.potencier.org/article/34/templating-engines-in-php

Provavelmente terei de concordar que o uso do PHP pode "complicar" alguns templates, sobretudo do ponto de vista de um Web Designer, e também pode "incentivar" o programador a fazer "asneiras" deixando-o implementar algumas tarefas que deveriam ter sido feitas no controlador ou no modelo.

Vamos ver como correm os desenvolvimentos do Twig até ao lançamento do symfony 2, mas a julgar pelo sucesso que foi a história do YAML, parece-me que a participação do Fabien neste projecto pode indiciar mais um caso de sucesso .

Developing for Facebook

Link: http://www.symfony-project.org/more-with-symfony/1_4/en/12-Developing-for-Facebook

(...)
- Choosing between FBML and XFBML: Problem solved by symfony
-  How Facebook Connect works and different Integration Strategies
- Best Practices for Facebook Applications
- Using symfony's logging System for debugging FBML
-  Using a Proxy to avoid wrong Facebook Redirections
- Redirecting inside an FBML application
(...)

Gerar gráfico do modelo de dados

Plugin: http://www.symfony-project.org/plugins/sfDoctrineGraphvizPlugin

Programa para visualizar os gráficos: http://www.graphviz.org/

Nota: Para instalar é necessário usar a opção --stability=beta (uma vez que o plugin ainda está numa versão beta).




Obrigado ao Filipe pera dica!

Inserir valores extra nos formulários antes da validação

Retirado daqui:

http://groups.google.com/group/symfony-users/browse_thread/thread/c4a90c5a140a90ed

O problema é:
- quero especificar o ACCOUNT_ID no objecto a ser editado/criado, mas sem que esse valor alguma vez passe para o utilizador sob a forma de hidden field.
- quero ainda manter o validador do formulário para garantir que esse account_id existe. Além disso quero manter o estado original no backend (admin generator)

1ª hipótese ("martelada"):
Fazer set ao validator - sfValidatorPass(), e inserir de account_id o valor no controller ou no $form->updateObject()

2ª hipótese:
Se o account_id é determinado na action, ou seja, não pode ser obtido a partir do objecto em si (nesse caso alteraria dentro do próprio ojecto),  então colocar o valor de account_id numa option do form e de seguida adicionar esse valor usando updateObject() . Como, desta forma, o account_id nunca entra no "mundo" do utilizador não há necessidade de o validar. As validações de base de dados garantem que não ocorre nenhum erro inesperado.

3ª hipótese:
Popular o objecto antes de o passar ao form, ou depois de fazer bind (antes de fazer save()). Neste caso para manter a lógica do account_id completamente fora da class form.

4ª hipótese:
Fazer merge do account_id no array que é passado ao bind. Desta forma tudo se processa como se o account_id tivesse sido submetido. Para manter a validação deve-se manter o validator e apenas fazer unset do widget.

Interactive embedded forms

Tutorial: http://redotheoffice.com/?p=42

Download de uma aplicação com exemplo: aqui.

Confesso que ainda não experimentei, mas pareceu-me bem. Fica a dica.

How to Write Plugins for symfony

Apresentação oficial pelo Fabien Potencier, sobre como criar plugins no symfony.
Note-se a nuance:

Choose a prefix (sf is only for oficial plugins) your initials for example.

Write Plugins for symfony (Symfony Camp 2007)

View more presentations from Fabien Potencier.

Esconder filtros na Administração

Solução semelhante à que eu uso aqui.