From 00e62b0d3a1d808991c17d71a3e766818764fb24 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9drix?= Date: Sat, 16 May 2026 09:24:55 +0200 Subject: [PATCH] =?UTF-8?q?add:=20PHP=20Object=20Generator=20(POG)=20:=20r?= =?UTF-8?q?etour=20sur=20une=20relique=20de=20l'=C3=A8re=20PHP4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- dd71de22-b863-45c5-87df-0cff7b1c6ee5/index.md | 43 +++++++++++++++++++ .../meta.json | 20 +++++++++ 2 files changed, 63 insertions(+) create mode 100644 dd71de22-b863-45c5-87df-0cff7b1c6ee5/index.md create mode 100644 dd71de22-b863-45c5-87df-0cff7b1c6ee5/meta.json diff --git a/dd71de22-b863-45c5-87df-0cff7b1c6ee5/index.md b/dd71de22-b863-45c5-87df-0cff7b1c6ee5/index.md new file mode 100644 index 0000000..58e9822 --- /dev/null +++ b/dd71de22-b863-45c5-87df-0cff7b1c6ee5/index.md @@ -0,0 +1,43 @@ +# PHP Object Generator (POG) : retour sur une relique de l'ère PHP4 + +Dans le paysage des outils PHP, certains projets témoignent d'une époque révolue. **PHP Object Generator**, ou POG pour les intimes, est de ceux-là. Hébergé sur le compte GitHub de Joel Wan, ce générateur de code se présente comme un ORM minimaliste destiné à automatiser la création de la couche d'accès aux données. + +## Le concept + +L'idée derrière POG est simple et, à l'origine, plutôt astucieuse : épargner au développeur PHP la corvée des CRUD répétitifs. À partir d'une définition d'objet, POG génère automatiquement une classe PHP avec ses méthodes `save()`, `get()`, `delete()`, etc., prêtes à dialoguer avec la base de données. Le README résume bien la philosophie : *"a large portion of a PHP programmer's time is wasted on repetitive coding of the Database Access Layer"*. Le temps économisé sur la plomberie peut être réinvesti dans la logique métier. + +Le projet propose deux modes d'utilisation : auto-hébergé (on extrait le code sur un serveur, on édite `include/configuration.php`, et on pointe le navigateur sur `index.php`) ou via le site phpobjectgenerator.com qui propose une interface en ligne. + +## Le contexte historique + +POG date du milieu des années 2000. À l'époque, **PHP 4 dominait encore** et PHP 5 venait à peine d'introduire un vrai modèle objet. Les frameworks modernes comme Symfony et Laravel n'existaient pas, Doctrine n'en était qu'à ses balbutiements, et la communauté PHP cherchait des solutions pragmatiques pour structurer son code. Dans ce contexte, POG apportait une vraie valeur : un générateur de code accessible, sans dépendances lourdes, qui produisait du PHP orienté objet propre. + +## L'état actuel du projet + +Là où le bât blesse, c'est en regardant le repo aujourd'hui : + +- **29 étoiles, 30 forks, 46 commits** au total — l'adoption est marginale et l'activité minimale +- Le projet revendique la compatibilité **PHP4/PHP5**, deux versions abandonnées par leurs mainteneurs depuis plus d'une décennie (PHP 5 a vu son support EOL en 2018, PHP 4 bien avant) +- Le repo contient des fichiers comme `index.php`, `index2.php`, `index3.php`, `pog.js`, `pog(2).js`, `pog1.js` — un éparpillement qui trahit l'absence de versioning propre du code source +- Le `jquery.js` est embarqué directement à la racine, à l'ancienne +- Aucun `composer.json`, donc pas d'intégration à l'écosystème PHP moderne via Composer/Packagist + +## Mon avis franc + +Soyons honnête : **ce projet n'est ni magnifique ni recommandable pour un usage en 2026**. C'est une pièce intéressante d'**archéologie logicielle**, pas un outil sur lequel construire quoi que ce soit aujourd'hui. Plusieurs raisons : + +D'abord, **l'écosystème a complètement changé**. Doctrine ORM, Eloquent (Laravel), Cycle ORM offrent aujourd'hui des solutions matures, maintenues, testées, intégrées aux frameworks, avec une gestion fine des migrations, des relations complexes, du lazy loading, du caching. POG joue dans une catégorie qui n'existe plus. + +Ensuite, **cibler PHP 4/5 est un signal d'alerte sécurité**. Le code généré ne profite ni du typage strict, ni des attributes PHP 8, ni des enums, ni du moindre apport des dix dernières années du langage. Réutiliser tel quel du code pensé pour ces versions, c'est s'exposer à des vulnérabilités (injections SQL si l'échappement n'est pas rigoureux, notamment) et à un code immédiatement legacy. + +Enfin, **le projet semble en sommeil**. Peu de contributeurs, peu de mouvement, et un README sans tests visibles ni documentation à jour. + +Cela dit, **POG a une vraie valeur historique**. Pour qui s'intéresse à l'évolution des pratiques PHP, à la genèse des générateurs de code, ou qui enseigne l'histoire du développement web, c'est un témoin précieux d'une époque où la communauté PHP construisait ses propres outils, parfois maladroitement, mais avec un vrai esprit d'entraide. Le `phpobjectgenerator.com` en ligne reste d'ailleurs un petit objet de curiosité. + +## Si tu cherches à faire ce que POG promettait + +Pour un projet neuf en 2026 : +- **Doctrine ORM** pour une approche Data Mapper rigoureuse +- **Eloquent** (utilisable hors Laravel via `illuminate/database`) pour de l'Active Record agréable +- **Cycle ORM** comme alternative moderne et performante +- Les **attributes PHP 8** pour décrire tes entités sans générateur de code diff --git a/dd71de22-b863-45c5-87df-0cff7b1c6ee5/meta.json b/dd71de22-b863-45c5-87df-0cff7b1c6ee5/meta.json new file mode 100644 index 0000000..62615aa --- /dev/null +++ b/dd71de22-b863-45c5-87df-0cff7b1c6ee5/meta.json @@ -0,0 +1,20 @@ +{ + "uuid": "dd71de22-b863-45c5-87df-0cff7b1c6ee5", + "slug": "php-object-generator-pog-retour-sur-une-relique-de-l-ere-php4", + "title": "PHP Object Generator (POG) : retour sur une relique de l'ère PHP4", + "author": "cedric@abonnel.fr", + "published": false, + "featured": false, + "published_at": "2026-05-16 07:24:55", + "created_at": "2026-05-16 07:24:55", + "updated_at": "2026-05-16 07:24:55", + "revisions": [], + "cover": "", + "files_meta": [], + "external_links": [], + "seo_title": "", + "seo_description": "", + "og_image": "", + "category": "", + "tags": [] +}