Posts Tagged ‘symfony’

Comment ajouter un commentaire à une table, ou mieux, à un champ dans ma base de données, depuis mon schema.yml ?

Avec la propriété « description » :

article_id:
{type: TINYINT,
required: true,
default: '0',
description: 'référence à un article',
FK: { type: INTEGER, required: true, foreignTable: article, foreignReference: id }'
}
Publicités

Doctrine vs Propel

Durant les formations Symfony, on me pose régulièrement la question : mais quel est le meilleur ORM, Propel ou Doctrine ?

La réponse, mon ami, est soufflée dans le vent,
La réponse est soufflée dans le vent.

J’ai donc décidé de commencer ma réponse par les liens des gens qui en parlent :

Une petite recherche Google vous aidera pas mal aussi (et vous retrouverez ceux que je viens de vous citer).

Et comme il faut toujours aller chercher l’information à la source, je vous enjoins de lire l’article (d’il y a 6 mois déjà) du blog de Symfony Project : What’s up with Propel and Doctrine ? (1.3)

Le contexte : une application PHP/MySQL, un champ BLOB dans l’application avec Symfony. Par défaut, nous avions laissé Propel pour faire nos tests.

Le souci d’un champ BLOB est sa contenance. Lorsque je veux lister tous mes enregistrements, si un des champs est BLOB, il est difficile de l’afficher directement dans le listing. Au niveau de la modélisation, j’ai donc intérêt à prévoir que ce champ sera ramené plus tard.
Symfony-Propel me propose une technique : préciser dans le YAML que ce champ sera rapporté à la demande.
commentaires_longs: {type: blob, lazyLoad: true}

Ensuite, lors de la récupération, j’ai tout intérêt à proposer un lien vers le contenu long (en saupoudrant éventuellement d’Ajax pour fournir à l’utilisateur une prévisualisation au survol). Il serait en effet trop coûteux de rapporter ce champ, en performance et en place sur la page web.
Au moment où je souhaite obtenir le commentaire, je pourrais faire :
$criteria->clearSelectColumns();
$criteria->addSelectColumn(ObjetPeer::COMMENTAIRES_LONG);
$rs =ObjetPeer::doSelectStmt($criteria);

Attention : actuellement, la méthode est doSelectStmt() et plus doSelectRS(), ne vous faites pas avoir.
Ensuite, vous récupérez un objet de la classe PDOStatement, il faut ensuite l’exploiter avec un fetch().

Au niveau de la conception de l’application, on peut imaginer mettre ces champs longs dans des tables séparées, puisqu’il sera rare qu’on les reprenne en même temps que les autres.

Petit aide-mémoire que je complète au fur et à mesure.

Les nouvelles commandes sont bien plus agréables et bien plus logiques. Elles ont été regroupées en espaces de noms.

symfony generate:module nomprojet nommodule

symfony propel:build-all

Enfin l’information que je cherchais depuis une heure, à savoir, comment supprimer le champ created_at de mon formulaire (généré automatiquement) de création d’item :

Pour supprimer un champ, il est nécessaire de supprimer son validateur et son widget.

Une autre façon, qui n’est pas nouvelle, mais qui rejoint les difficultés de symfony : il ne faut pas mettre de else aux if isValid(), car sinon le flux de validation du formulaire ne s’effectue pas.

if($request->isMethod('post'))
{
$this->form->bind($request->getParameter('unbug'));
if($form->isValid())
{
$form->save();
$this->redirect('bugs/lister');
}
}

Et ce qu’il y a de bon à savoir avec les formulaires, c’est que les classes liées (relation 1-N) doivent avoir une méthode toString() pour pouvoir être utilisable via la génération automatique de CRUD.
En mode dev (appli_dev.php/module/action) le message s’affiche clairement.