Si vous avez essayé de créer votre propre widget, vous avez du vous apercevoir que le rendu est fait a l'intérieur de la fonction sfWidget->render(). Ce qui suffit pour des rendus simples, mais s'avère inapproprié lorsque votre champ de formulaire se complexifie. La structure vue-contrôleur du framework n'est pas respectée.

Pour compenser ce manque, j'ai créé un widget dont le rendu se fait via un composant (component) ou une vue partielle (partial). Ce widget est destiné à faciliter la création de champ de formulaire spécifiques pouvant utiliser entre autre AJAX, le profil de l'utilisateur, l'objet sfContext et sfRequest...

# /lib/widget/sfWidgetFormComponent.class.php
/**
 * sfWidgetComponent is a widget rendered on a component.
 * The component will recieve this vars :
 *  * $name        The element name
 *  * $value       The value selected in this widget
 *  * $attributes  An array of HTML attributes to be merged with the default HTML attributes
 *  * $errors      An array of errors for the field
 *  * $id          An unique id
 *  * $is_hidden   Is the field hidden ?
 *
 * @package    core
 * @subpackage widget
 * @author     Jerome TAMARELLE <http://jerome.tamarelle.net/>
 */
class sfWidgetFormComponent extends sfWidgetForm
{
  /**
   * Constructor.
   *
   * Available options:
   *  * module:       The module name
   *  * component:    The component name
   *  * context:      Current context object
   *
   * @param array $options     An array of options
   * @param array $attributes  An array of default HTML attributes
   * @see sfWidgetForm
   */
  protected function configure($options = array(), $attributes = array()) {
    $this->addRequiredOption('module');
    $this->addRequiredOption('component');
    $this->addOption('is_partial', false);
    $this->addOption('context', sfContext::hasInstance() ? sfContext::getInstance() : null);
  }

  /**
   * @param  string $name        The element name
   * @param  string $value       The value selected in this widget
   * @param  array  $attributes  An array of HTML attributes to be merged with the default HTML attributes
   * @param  array  $errors      An array of errors for the field
   * @return string The rendered component
   * @see sfWidgetForm
   */
  public function render($name, $value = null, $attributes = array(), $errors = array()) {
    try {
      $this->getOption('context')->getConfiguration()->loadHelpers('Partial');
    } catch (Exception $e) {
      throw new Exception('sfWidgetFormComponent requires &quot;context&quot; option to be an instance of sfContext.');
    }

    $vars = array(
      'name'        => $name,
      'value'       => $value,
      'attributes'  => $attributes,
      'errors'      => $errors,
      'id'          => $this->generateId($name),
      'is_hidden'   => $this->getOption('is_hidden'),
    );

    if($this->getOption('is_partial')) {
      return get_partial($this->getOption('module').'/'.$this->getOption('component'), $vars);
    } else {
      return get_component($this->getOption('module'), $this->getOption('component'), $vars);
    }
  }
}

sfWidgetFormComponent est un widget comme les autres ! Pour l'utiliser il suffit de l'ajouter à votre formulaire dans la fonction configure() de celui-ci.

# /lib/form/MyModelForm.class.php
class MyModelForm extends BaseMyModelForm {
  public function configure() {
    $this->setWidget('field',
      new sfWidgetFormComponent(array(
                      'module'=>'ajax',
                      'component'=>'myModelWidget'
    )));
  }
}

Il ne vous reste plus qu'à créer le composant qui conviendra le mieux à votre besoin !

• Widgets de l'API Symfony
• Plugins Symfony de la catégorie Widget
• Au Coeur des Widgets et Validateurs
• Personnaliser le code d'un widget
• Générer un formulaire en fonction de l'utilisateur

A quoi sert le paramètre with_show dans le fichier generator.yml ?

Aussi surprenante soit-elle, la réponse usuelle à cette question est :

Par défaut, à rien...

Alors comment afficher les détails d'un objet dans une page d'administration sans que celles-ci soient modifiables ? il est bien nécessaire d'activer l'action show. Les plugins sfDoctrineAdminGeneratorWithShowPlugin et sfPropelAdminGeneratorWithShowPlugin ont été créés pour compenser ce manque. Malheureusement ils ne fonctionnent que pour Symfony 1.2 et 1.3.

Paralysé par cette absence d'action show sous Symfony 1.4, je me suis lancé dans la correction du plugin sfDoctrineAdminGeneratorWithShowPlugin pour le rendre compatible.

Télécharger sfDoctrineAdminGeneratorWithShowPlugin pour Symfony 1.4

Pour installer le plugin, décompressez l'archive dans le répertoire plugin/ de votre projet Symfony.

Activez le plugin en modifiant le fichier config/ProjectConfiguration.class.php

$this->enablePlugins('sfDoctrinePlugin','sfDoctrineAdminGeneratorWithShowPlugin');

Générez le module d'administration :

./symfony doctrine:generate-admin --theme=adminWithShow application ClasseExemple

Activez l'action vue dans le fichier application/modules/classe_exemple/config/generator.yml

    with_show: true

Cela donne par exemple :

generator:
  class: sfDoctrineGenerator
  param:
    model_class:           ClasseExemple
    theme:                 adminWithShow
    non_verbose_templates: true
    with_show:             true
    singular:              ~
    plural:                ~
    route_prefix:          classe_exemple
    with_doctrine_route:   true

    config:
      actions: ~
      fields:  ~
      list:    ~
      filter:  ~
      form:    ~
      edit:    ~
      new:     ~
      show:    ~

Maintenant que l'action show est ajoutée, vous pouvez personnaliser à souhait votre module d'administration en modifiant le fichier generator.yml et/ou les templates. Toute la documentation utile est sur le site du framework.

1. Depuis la console (communément appelé CLI)
2. Depuis une adresse locale (localhost)
3. Depuis une requête AJAX (ou XMLHttpRequest JavaScript)
4. En mode debug
5. Contexte d'exécution

La fonction php_sapi_name retourne le type d'interface utilisée, par exemple "cli" ou "cgi". En analysant la valeur retournée par cette fonction vous pouvez donc facilement détecter une exécution dans la console PHP. Dans Symfony, ce sont les tâches qui sont généralement exécutées par cette interface.

if(php_sapi_name() == 'cli')
{
  // Code exécuté uniquement lorsque le script est appelé en ligne de commande (cli).
}

Symfony fait déjà cette détection par défaut dans le fichier app_dev.php pour empêcher l'exécution de l'application en mode debug depuis d'extérieur. Les adresses 127.0.0.1 et ::1 sont les adresses IP v4 et v6 normalisées de rebouclage sur la machine locale, la condition ci-dessous vérifie que la requête est transmise depuis l'une de ces deux adresses.

if (in_array($this->getRequest()->getRemoteAddress(), array('127.0.0.1', '::1')))
{
  // Code exécuté uniquement lorsque l'application est exécutée depuis une adresse locale.
}

Parmi les fonctionnalités magiques de Symfony, vous pouvez appelé la fonction sfWebRequest::isXmlHttpRequest() depuis vos sfAction(s). Vous saurez alors si la page a été appelée depuis JavaScript.

if($this->getRequest()->isXmlHttpRequest())
{
  // Code exécuté uniquement lorsque l'action est appelée depuis JavaScript
}

Lorsque votre application est exécutée en mode debug, la constante sf_debug prend la valeur true. Il vous est donc facile de n'afficher certaines informations que pour le développement et le débogage de votre application.

if(sfConfig::get('sf_debug'))
{
  // Code exécuté uniquement lorsque l'application est exécutée en mode debug
}

(Ajouté le 04/02/2010)

Pour éviter l'erreur « The "default" context does not exist. » lorsqu'on utilise i18n ou doctrine dans les models/widgets par exemple.

if(sfContext::hasInstance())
{
  $contexte = sfContext::getInstance();
  // Code exécuté uniquement lorsque l'application est exécutée avec un contexte (depuis une application).
}