CRUD simple / réutilisable en PHP (PAS de travail de renommée ou de grandes classes)

Question

Je travaille sur un projet de type PHP CMS et j'essaie de découvrir quel est le moyen le plus pratique de gérer la fonctionnalité CRUD en PHP.

Le CMS est entièrement programmé en PHP procédural (pas de POO - je sais que beaucoup d'entre vous ne seront pas d'accord avec cela...) et a été conçu pour que tout soit aussi simple et léger que possible, tout en créant des fonctions et des extraits de code hautement réutilisables. .

Le CMS permet d'installer/activer plusieurs modules en fonction des besoins.Ces modules décrivent différents types de contenu, donc je finirai probablement par avoir quelque chose comme des pages, des actualités, des blogs pour n'en nommer que quelques-uns.

Pour chacun de ces types de contenu, je devrai créer les opérations CRUD et j'essaie maintenant de trouver le moyen le plus pratique d'y parvenir.

Une exigence serait que le formulaire pour chacun de ces types de contenu soit contenu dans un seul fichier externe (à la fois pour l'insertion et la modification) et s'il existe un moyen d'intégrer la validation des entrées côté serveur, ce serait un plus.

Answer 1

Par opérations CRUD, entendez-vous uniquement les requêtes (fastidieuses) de base de données ?

Vous pouvez tout aussi facilement configurer votre base de données de sorte qu'à l'exception de quelques champs communs parmi les types de contenu, toutes les données d'un type de contenu particulier soient stockées sous forme de tableau associatif sérialisé dans un champ TEXTE.

De cette façon, vous n'avez besoin que d'un seul ensemble de requêtes pour CRUD, quel que soit le type de contenu particulier, car les données transmises aux fonctions CRUD sont simplement sérialisées aveuglément.

Par exemple, disons que nous déclarons que le titre du contenu, la date de création/mise à jour, les balises et la brève description sont considérés comme des données communes.De là, nous avons un blog et un type de contenu de page.

Je créerais éventuellement une table de base de données comme telle :

CREATE TABLE `content` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `name` VARCHAR  NOT NULL,
  `short_description` TEXT  NOT NULL,
  `tags` TEXT ,
  `data` TEXT ,
  `content_type` INT  NOT NULL,
  `created_at` DATETIME  NOT NULL,
  `updated_at` DATETIME  NOT NULL,
  PRIMARY KEY (`id`)
)

(Allez-y et supposez que nous allons créer les tables de référence pour content_type)

Et même si le blog peut nécessiter des données telles que des « pingbacks » et que la page ne nécessite rien d'autre que le corps, vous stockez simplement la sortie de quelque chose comme l'exemple ci-dessous pour un blog :

$data = serialize(array(
    "body" => "Lorem ipsum",
    "pingbacks" => array()
));

Les mises à jour sont faciles : chaque fois que vous récupérez les données de la base de données, vous désérialisez les données pour les modifier dans un formulaire sélectionné en fonction du type de contenu.L'affichage fonctionne de la même manière, prenez simplement un modèle basé sur le type de contenu et envoyez-lui le tableau de données non sérialisées.Le modèle n'a jamais besoin de se soucier de la manière dont les données sont stockées, il suffit simplement d'obtenir un $data['pingbacks'].

En ce qui concerne vos formulaires, ma suggestion est de rompre votre engagement anti-POO et de trouver une bibliothèque de génération de formulaires.Si vous pouvez l'extraire du framework, en utilisant Zend_Form avec Zend_Config et Zend_Validate du Cadre Zend (tout ce que Zend_Config représente dans cette situation est une interface pratique pour charger et parcourir des fichiers XML et INI) rend la vie vraiment agréable.Vous pouvez demander à vos fichiers XML de définir le formulaire pour chaque type de contenu, et tout ce que vous feriez est simplement d'afficher le formulaire sur votre page (en saisissant le XML basé sur le type de contenu), en récupérant les données filtrées, en supprimant les "champs communs" comme nom, dates de création/mise à jour, puis sérialisation de ce qui reste dans la base de données.Aucune connaissance du schéma d'un type de contenu particulier n'est requise (sauf si vous souhaitez être strict).

Cependant, à titre personnel, je vous suggère fortement d'envisager de récupérer Zend_Form (avec Zend_Validate et Zend_Config) ainsi que d'utiliser Doctrine en tant que couche d'abstraction ORM/base de données.Vous constaterez peut-être qu'au moins Doctrine vous rendra la vie beaucoup plus facile lorsqu'il s'agira d'exécuter des opérations sur la base de données.

Answer 2

Cependant, à titre personnel, je vous suggère fortement d'envisager de récupérer Zend_Form (avec Zend_Validate et Zend_Config) ainsi que d'utiliser Doctrine comme couche d'abstraction ORM/base de données.Vous constaterez peut-être qu'au moins Doctrine vous rendra la vie beaucoup plus facile lorsqu'il s'agira d'exécuter des opérations sur la base de données.

Je suis d'accord avec décousineau.Pourquoi rouler le vôtre quand c'est déjà fait ?j'irais aussi voir Base de données Zend, et si vous avez besoin d'une solution PHP4 et 5 PHP ADODB.

J'ai commencé un projet académique récemment et j'avais la même envie que vous ;finalement, je suis allé avec PHP ADoDB.

Answer 3

Je suggère www.ajaxcrud.com - il est facile à utiliser, léger et vous permet d'être opérationnel en quelques secondes.

Answer 4

Vous pouvez essayer ceci : http://xcrud.com, vraiment utile