Génération PHP

Bonjour,
Je viens d'attaquer le développement du module PHP de mon générateur de sites web et déjà quelques questions se posent par rapport à l'environnement Java / Servlet que je pratique plus couramment.
Après avoir parcouru un certain nombre d'articles (notamment php.net) et visionné quelques vidéos traitant du sujet, il me semble avoir compris que pour la mise en place d'un site PHP, ex nihilo, la pratique la plus courante consiste à :
a) créer un "contrôleur front end" (ou "super contrôleur"), la plupart du temps dénommé index.php, recevant les URL demandées par l'utilisateur et servant de routeur
b) créer N contrôleurs dédiés, correspondant chacun à une URL et fournissant en retour le contenu correspondant
c) mettre en place sur le serveur HTTP une redirection permanente, au niveau du fichier .htaccess, afin que toutes les requêtes entrantes soient systématiquement envoyées au routeur précité.
Est-ce exact jusqu'ici ?
Si c'est le cas, je vois déjà une première différence de taille avec les servlets Java / serveur Tomcat (ou autres) dans la mesure où une servlet est, structurellement, un routeur qui reçoit toutes les requêtes reçues par le serveur.
Il n'y a donc aucune configuration particulière à faire au niveau du serveur, autre que la déclaration de la servlet correspondant au site web. Bien qu'il soit toujours possible d'en déclarer plusieurs, avec des URL différentes, ce cas de figure n'est pas d'usage courant pour un même site.
Dès lors, et avant de développer en détail le module PHP du générateur, je voudrais m'assurer que :
a) le principe du contrôleur front end + N contrôleurs dédiés + redirection serveur HTTP est pertinent
b) savoir si ce principe est le plus utilisé (notamment en MVC) ou s'il existe d'autres approches
c) si, comme je le crains, la redirection serveur est tributaire du type dudit serveur et doit donc être adaptée en conséquence
Je précise que pour l'instant, il s'agit de générer un site en PHP "pur", c'est à dire hors framework tel que Symfony ou autre. L'intégration de ces frameworks dans le générateur sera réalisée en suivant, une fois les bases posées.
A priori, et pour conserver sa généricité au générateur web, je pense intégrer la possibilité de basculer entre le mode décrit ci-dessus et un mode sans contrôleurs dédiés via une propriété située au niveau des options projet.
Si j'ai bien compris la problématique en question, ceci devrait permettre de créer des fichiers PHP correspondant à chaque URL, c'est à dire sans contrôleur et sans redirection serveur, supprimant ainsi la dépendance par rapport à un environnement extérieur qu'on ne contrôle bien souvent pas (cf. billets récurants sur ce forum à propos des configurations .htaccess) et des typologies de serveurs qui varient (bien que Apache soit un standard bien installé).
Merci de m'indiquer si je fais erreur dans l'approche ci-dessus et sur quels points, afin que je puisse adapter mon code en conséquence.

Bonjour!

a écrit :
c) mettre en place sur le serveur HTTP une redirection permanente, au niveau du fichier .htaccess, afin que toutes les requêtes entrantes soient systématiquement envoyées au routeur précité.

C'est de l'URL rewriting et non de la redirection permanente. Ce qui signifie que tu as une adresse du genre -www.monsite.com/index.php?q=animaux/canard et que tu vas réécrire une forme telle que: -www.monsite.com/animaux/canard pour que le serveur comprenne la première forme. Mais il n'y a pas de redirection. C'est juste une traduction plus claire pour l'utilisateur et plus compatible pour le référencement. Mais la forme originale reste, ce qui signifie que l'URL rewriting est optionnel, et que donc le modèle de front-controller n'est pas du tout tributaire du type de serveur.

Concernant les serveurs, pour du php, la majorité est clairement de l'apache, particulièrement chez les hébergeurs mutualisés. Il y a ensuite Nginx (pour lequel tu peux fournir la méthode de réecriture), et finalement lightHttpd, qui peut aussi supporter l'URL rewriting. Mais pour ce dernier ou d'autres solutions exotiques, elles sont généralement utilisées par des personnes qui savent ce qu'elles font. En ne fournissant que l'URL rewriting apache, tu toucheras donc 99.9% des gens qui n'y comprenne rien à tout ça.

a écrit :
savoir si ce principe est le plus utilisé (notamment en MVC) ou s'il existe d'autres approches

C'est très clairement le plus utilisé. L'autre option la plus fréquente et qui était autrefois la principale est d'aller «dans l'autre sens»: chaque partie du site correspond à un fichier php que l'on appelle, qui commence par inclure un fichier de «boot» générique. Si cette méthode est toujours utile pour de petits projets, elle montre vite des limites sur la maintenance, le travail collaboratif, la sécurité, la dette technique, etc. au fur et à mesure que le projet se complexifie.

Cependant si j'ai bien compris ton problème, ton code «générera» du code PHP, ce qui fait que la logique permettant de générer le site ne se trouve ni dans la structure du code PHP ni dans le PHP lui-même? Si j'ai bien compris ces problématiques ne concerne pas vraiment ton projet et le modèle plus simple pourrait parfaitement convenir.

a écrit :
Je précise que pour l'instant, il s'agit de générer un site en PHP "pur", c'est à dire hors framework tel que Symfony ou autre. L'intégration de ces frameworks dans le générateur sera réalisée en suivant, une fois les bases posées.

Là je bloque, ces questions de contrôleurs, router, structure du code de l'application sont en quelque sort l'ADN de ces frameworks, c'est la première chose qu'ils réalisent. Tu ne peux pas vraiment dissocier ces bases du choix d'un framework…

Merci kustolovic pour ces réponses très précises.

kustolovic a écrit :
C'est de l'URL rewriting et non de la redirection permanente. Ce qui signifie que tu as une adresse du genre -www.monsite.com/index.php?q=animaux/canard et que tu vas réécrire une forme telle que: -www.monsite.com/animaux/canard pour que le serveur comprenne la première forme. Mais il n'y a pas de redirection. C'est juste une traduction plus claire pour l'utilisateur et plus compatible pour le référencement. Mais la forme originale reste, ce qui signifie que l'URL rewriting est optionnel, et que donc le modèle de front-controller n'est pas du tout tributaire du type de serveur.
Concernant les serveurs, pour du php, la majorité est clairement de l'apache, particulièrement chez les hébergeurs mutualisés. Il y a ensuite Nginx (pour lequel tu peux fournir la méthode de réecriture), et finalement lightHttpd, qui peut aussi supporter l'URL rewriting. Mais pour ce dernier ou d'autres solutions exotiques, elles sont généralement utilisées par des personnes qui savent ce qu'elles font. En ne fournissant que l'URL rewriting apache, tu toucheras donc 99.9% des gens qui n'y comprenne rien à tout ça.

Effectivement, je me suis mal exprimé en parlant de « redirection permanente » qui relève plutôt du HTTP 301.
De fait, je parlais d'une forme d'alias qui voit une URL en entrée, saisie par l'utilisateur, convertie par le serveur en une seconde URL récupérée et traitée spécifiquement, le tout de façon transparente pour le client web qui s'est connecté.
Tes infos sur les types de serveurs HTTP rencontrés confirment ce que j'ai pu lire par ailleurs, notamment sur leur répartition et le poids quasi monopolistique d'Apache en ce domaine.
C'est d'ailleurs la configuration que j'ai adoptée pour mes tests en local, mais dans sa version « à l'ancienne », c'est à dire une installation totalement manuelle avec PHP, sans passer par WAMP et consorts dont l'utilité n'est pas remise en question mais ne correspondent pas à mes besoins du moment.
Ta réponse confirme par ailleurs, sauf mauvaise lecture de ma part, que le format de la configuration varie d'un type de serveur à l'autre (Apache, Nginx, etc.), ce qui m'amenait à penser qu'elle induit une forme de dépendance lors de l'installation.
Le générateur web en cours de développement doit être programmé pour pouvoir sérialiser le contenu du fichier .htaccess en conformité avec les choix faits au niveau du projet. Pour être exhaustif, je devrais donc me préoccuper également de ce type de configuration lorsque le serveur cible ne sera pas de l'Apache.
Même si cela ne concerne que très peu de sites, le générateur se doit d'être complet sur ce point. Compte tenu toutefois de la rareté du besoin, ceci sera traité dans une seconde phase, priorité étant donnée à Apache.

kustolovic a écrit :
C'est très clairement le plus utilisé. L'autre option la plus fréquente et qui était autrefois la principale est d'aller «dans l'autre sens»: chaque partie du site correspond à un fichier php que l'on appelle, qui commence par inclure un fichier de «boot» générique. Si cette méthode est toujours utile pour de petits projets, elle montre vite des limites sur la maintenance, le travail collaboratif, la sécurité, la dette technique, etc. au fur et à mesure que le projet se complexifie.
Cependant si j'ai bien compris ton problème, ton code «générera» du code PHP, ce qui fait que la logique permettant de générer le site ne se trouve ni dans la structure du code PHP ni dans le PHP lui-même? Si j'ai bien compris ces problématiques ne concerne pas vraiment ton projet et le modèle plus simple pourrait parfaitement convenir.

Tu as parfaitement saisi les deux options qui se présentent à moi pour le développement du module PHP natif du générateur.
Grosso modo, je dois choisir entre :
a) n'offrir que le modèle routeur + contrôleurs + .htaccess
b) n'offrir que le modèle N contrôleurs correspondant chacun à une ressource
c) offrir le choix au niveau du projet pour générer la solution A ou la solution B
A priori, mon approche était correcte et tu confirmes donc explicitement mon analyse initiale, ce qui me permet de pouvoir passer au développement effectif du module PHP en intégrant la solution C. L'idée est en effet que le générateur colle au plus près des besoins pouvant être rencontrés.
Tu as bien saisi également ce que recouvre le terme « génération » et, effectivement, c'est le moteur Java qui va créer de toute pièce les fichiers PHP qui seront nécessaires à chaque solution, en adaptant par ailleurs le code produit à la version cible de PHP.
Bien que la 7 soit appelée à être celle de référence, je pense tout de même prendre en compte la 5, histoire de tenir compte du parc existant. Le basculement de l'une à l'autre se fera, là aussi, en changeant simplement une propriété au niveau des options projet.
Etant donné que le développement du module PHP m'amène à creuser de plus en plus ce langage, je vois pas mal de littérature où les évolutions entre versions sont mises en parallèle. Ecrire du code Java qui en tient compte n'est pas insurmontable et j'en profite pour capitaliser les connaissances acquises afin d'offrir une palette la plus large possible.

kustolovic a écrit :
Là je bloque, ces questions de contrôleurs, router, structure du code de l'application sont en quelque sort l'ADN de ces frameworks, c'est la première chose qu'ils réalisent. Tu ne peux pas vraiment dissocier ces bases du choix d'un framework…

Sur ce point également tu es dans le mille et l'idée n'est pas de remettre en question les frameworks existants.
En fait, le générateur doit permettre de créer des sites :
- en PHP natif hors framework
- en Symfony
- en XXX, framework existant ou à venir
mon code devant évoluer en fonction du domaine.
Le tout avec recours, ou non, à Bootstrap, Foundation, etc.
Les premiers essais de génération de site statique reposant sur Bootstrap donnent des résultats intéressants.
A présent je passe au dynamique en PHP, avant d'attaquer le dynamique en Java / Servlet (qui est plus mon domaine professionnel), ASP ou autre langage.
Hyper intéressant comme développement... et probablement viable à terme pour bâtir dessus une activité commerciale. Du moins, pour l'instant, je n'ai rien trouvé qui me laisse penser que ce ne soit pas faisable techniquement et rien non plus pour étayer le fait que ce genre de produit puisse n'intéresser personne.
Pouvoir basculer la totalité d'un site d'une version Symfony à une version N en changeant juste une propriété projet n'est pas le Saint-Graal des agences web, mais on s'en approche.
P'têt que ça marchera, p'têt que ça marchera pas, mais j'y travaille.

Personnellement j'ai vraiment du mal à saisir la plus value de ton générateur par rapport à un framework. C'est quoi l'intérêt de pouvoir passer d'un framework symphony à un framework lambda ?

bzh a écrit :
Personnellement j'ai vraiment du mal à saisir la plus value de ton générateur par rapport à un framework. C'est quoi l'intérêt de pouvoir passer d'un framework symphony à un framework lambda ?

C'est pourtant évident...
Je te garantis qu'une entreprise à qui tu permets de basculer la totalité d'un site de Java à PHP, ASP ou autre, instantanément et avec reprise immédiate des données, elle le voit très vite, elle, l'intérêt de l'outil.
Plus généralement, je parcours pas mal d'articles et de vidéos traitant de l'entreprenariat et des débuts de startups, pour lesquelles disposer d'un site web vitrine très rapidement et à moindre coût est particulièrement important.
Tu as dès lors le choix entre :
- faire appel à un free lance
- faire appel à une agence web
- te former
Certains ont trouvé le créneau suffisamment intéressant pour mettre en place des formations dédiées à ce type de population (cf. Le Wagon).
On peut toujours émettre des réserves sur la pertinence de ce type de formation accélérée mais, admettons que l'entrepreneur sorte de celle-ci apte à créer son site mono page qui va bien.
Que va-t-il faire lorsque, sa startup ayant grandi, il veut passer sur Wordpress, puis ensuite sur Drupal, toujours en maîtrisant ses coûts, en conservant ses données et dans les meilleurs délais ?
Aller voir un free lance ou une agence web reste pratiquement la seule option qui s'offre, sauf à repartir dans un cycle de formation plus aléatoire.
A contrario, si tu disposes d'un générateur à partir duquel tu peux basculer immédiatement ton site du mono page statique initial à Wordpress, voire directement sur Drupal, penses tu que le coût et la sécurité pour l'entrepreneur concerné seront les mêmes ?
A priori non.
Parcourir les forums et articles de blog permet aussi de jauger l'ambiance et, à ce que je vois, pas mal de gens se posent des questions quant aux failles de sécurité d'un Wordpress, par exemple, et envisagent de migrer vers autre chose.
Sauf que cela a un coût, un délai de réalisation et représente un risque.
Wordpress, vu par un informaticien, cela reste :
- une base de données lisible
- du HTML / CSS apte à être relu, analysé et reconstruit
Point de binaire là dedans... donc un générateur peut parfaitement analyser un existant et le remodeler pour utiliser un nouvel environnement / framework, en réduisant les délais et, donc, les coûts ce qui te permet de mettre sur le marché une offre commerciale intéressante.
Maintenant, tu peux rester non convaincu par le principe, chacun restant libre d'adhérer ou non.
Perso, je vois tout de même un certain nombre d'avantages supplémentaires à un générateur :
a) Veille techno permanente :
Si une faille de sécurité est décelée et/ou une optimisation de code proposée, on adapte le générateur en conséquence et on reconstruit les N sites utilisant la techno en question. Si tu me garantis pouvoir faire aussi bien, aussi vite ou mieux manuellement, je suis preneur.
b) Obsolescence d'un framework :
On en parle suffisamment souvent sur les forums, tout le monde sait bien qu'un framework lambda instant T sera peut-être, ou non, toujours existant à T+n.
Quid des sites web qui l'auront retenu comme base de développement ?
A mon avis, une possibilité de conversion rapide, voire instantanée, dans autre chose est susceptible d'intéresser les boîtes détentrices des sites web concernés. Mais, là aussi, je peux me tromper... sauf que dans ma boîte actuelle, vu la compression des budgets et le "toujours plus rapide", la petite musique qu'on entend pousse tout de même dans le sens d'un générateur.
c) Taux de renouvellement :
Ce n'est, là aussi, un secret pour personne, les boîtes comme la mienne utilisent un pourcentage particulièrement élevé de prestataires extérieurs avec un taux de renouvellement fréquent.
Du coup, je perds un bon développeur Java / Servlet, pour en recevoir un nouveau que sa SSII m'a, bien évidemment, présenté comme la huitième merveille du monde dans la maîtrise de Bootstrap ou autre.
Je peux toujours prendre pour argent comptant la parole d'un commercial... mais après presque quarante ans passés en milieu professionnel, il y a longtemps que je ne crois plus au Père Noël en la matière.
Le générateur lui, se fout pas mal de savoir si celui qui appuie sur le bouton pour créer / modifier un site en Bootstrap ou en tartempion est compétent ou non.
Le seul niveau de compétence requis est celui du gars qui a développé ledit générateur et intégré les frameworks dans toute leurs subtilités.
Là aussi, l'entreprise voit très vite le bénéfice qu'elle peut retirer de la pérénité de la connaissance liée au générateur et la fiabilité qui en découle.
On se plaint régulièrement, sur ce forum ou ailleurs, du fait que les agences web cherchent toujours le mouton à cinq pattes, le gars qui maîtrise sur le bout des doigts la quasi totalité des frameworks du marché. C'est une perle rare... et cela s'appelle un générateur sur pattes.
d) Rétro action
Je viens d'entamer cette semaine le développement du module PHP et la distinction entre versions dudit PHP est d'ores et déjà intégrée dans les classes Java.
De fait, si je sérialise un site en PHP 7.n, le module en question sait qu'il pourra générer des classes anonymes. Si la version est supérieure à 5.n, j'intègre d'office les espaces de noms, histoire de sécuriser le code PHP et lever tout conflit potentiel entre librairies.
Etc.
Au fur et à mesure où j'engrange des connaissances, ou analyse le source de frameworks bien installés, elles sont directement traduites en code Java au niveau du générateur.
Admettons que je livre un site censé être en PHP 7 mais que, pour diverses raisons, mon hébergeur décide qu'il faut rétro pédaler vers une version antérieure, ma seule action sera de changer une propriété au niveau du projet et de recréer le site.
A l'aise, blaise...
Tu me diras qu'il existe des logiciels de suivi de version tels que Git et autres. Bien vu... mais que t'apportes le fait de récupérer une version antérieure si entre temps une faille de sécurité a été corrigée et/ou une amélioration apportée ?
Le générateur ne se pose pas de questions existentielle sur le sujet. Si on lui demande une version antérieure, on l'obtient avec, de facto, toutes les garanties d'avoir un code bénéficiant des dernières mises à jour, corrections et bonifications apportées entre T et T-n.
Pas sûr que ce point soit purement théorique.
e) Documentation
Etant à l'origine de la sérialisation, le générateur est le mieux informé des détails d'une version de site web et peut te fournir la documentation qui va bien, dans plusieurs formats.
Des générations d'informaticiens ont trouvé, et trouvent toujours, ce travail de documentation particulièrement ch...., et s'y plient avec une mauvaise volonté évidente. Faire bosser un programme informatique à sa place pour obtenir un résultat plus rapide, plus fiable et plus fun, c'est assurément vendeur.
f) Travail en équipe
Etant prévu pour être en ligne, le générateur est structuré de façon à permettre d'intervenir à plusieurs sur le même projet à un instant T.
Si tu bosses seul, ce n'est certes pas un argument.
Dans le cas contraire, j'ose penser que certains pourront apprécier.
Là aussi, Git et consorts existent déjà, mais le périmètre et les fonctionalités sont différents (cf. supra point C).
Bref, tu n'es pas le premier et ne sera certes pas le dernier à émettre des doutes sur la pertinence d'un générateur tel que celui-ci et c'est assurément ton droit le plus strict.
Perso, je vois les choses un peu différemment et, pour l'instant, rien n'est venu contredire factuellement ce point de vue. Ceci dit, je reste toujours preneur de tout argument contradictoire venant me prouver qu'à un moment ou un autre je serai dans l'impasse.
C'est comme ça qu'on avance.
Enfin, dernier point sur la pertinence du générateur, tu penses bien que j'ai pris soin d'en discuter avec toute une bande de "vieux" développeurs que j'ai cotoyés et avec qui j'ai pu travailler par le passé. Si le principe était si déconnant, nul doute qu'ils n'auraient pas hésité à me le dire. Etonnamment, c'est plutôt le contraire qui s'est passé et ils sont demandeurs de pouvoir tester l'outil dès que l'éditeur en ligne sera disponible.
Connaissant leurs domaines d'expertise respectifs, j'ai tendance à me fier à leur jugement.
Modifié par sepecat (19 Mar 2017 - 09:05)

Pour ma part je peine vraiment à comprendre l'intérêt avec les frameworks.

Pour la génération de site statique je peux bien comprendre. ça peut effectivement s'étendre à du php basique, même si le modèle de front-controller me parait du coup pas très utile (vu qu'on ne lit ni ne modifie jamais le php).

Car pour que ce système fonctionne, il faut que l'on ne modifie jamais le code généré (sinon on ne pourra plus le regénérer), ainsi le générateur prend le rôle de préprocesseur, mais un préprocesseur générique qui prend en compte toutes les situations. Outre l'aspect titanesque du travail, je ne comprends l'intérêt de générer du code d'un framework.

Un framework fourni un cadre, une méthodologie de travail et des outils afin de, principalement, permettre au développeur de ne se concentrer que sur la partie logique, qui résulte de choix du développeur, et non toutes les parties répétitives et techniques du logiciel. Ceci permet d'accélérer le développement, de faciliter la maintenance et le travail collaboratif. En contrepartie, les frameworks sont gourmands et entraîne des pertes de performances (que l'on peut limiter avec de plus grosses machines, des systèmes de cache, etc.).

Du coup si je développe la logique dans ton générateur, qui se trouve être le framework, quel est l'intérêt de générer du Symfony ensuite, plutôt que du php sans framework? Hormis une perte de performance, aucun des avantages du framework ne nous sert à quoi que ce soit!

a écrit :

a) Veille techno permanente :
Si une faille de sécurité est décelée et/ou une optimisation de code proposée, on adapte le générateur en conséquence et on reconstruit les N sites utilisant la techno en question. Si tu me garantis pouvoir faire aussi bien, aussi vite ou mieux manuellement, je suis preneur.

Une faille est détectée dans Drupal, Drupal publie un correctif, ce correctif est inclu dans ton générateur, tu publies un correctif. Le générateur ne rajoute rien en sécurité, il allonge juste la chaine de résolution. Quel est ta vitesse de réponse, combien de personnes publient des correctifs? Peut-tu rivaliser avec les milliers de contributeurs professionnels de ce genre de solutions? En matière de veille, tu peux difficilement faire mieux que ce qui se fait pour les grands frameworks et CMS.

a écrit :

On en parle suffisamment souvent sur les forums, tout le monde sait bien qu'un framework lambda instant T sera peut-être, ou non, toujours existant à T+n.
Quid des sites web qui l'auront retenu comme base de développement ?

Il en va de même pour ton générateur. C'est toujours une question de gestion des risques. Mais un framework libre utilisé par une grosse base d'utilisateur sera bien plus pérenne qu'un générateur développé par un particulier, ce ne peut être (pour le moment) un argument de vente.

a écrit :

Des générations d'informaticiens ont trouvé, et trouvent toujours, ce travail de documentation particulièrement ch...., et s'y plient avec une mauvaise volonté évidente. Faire bosser un programme informatique à sa place pour obtenir un résultat plus rapide, plus fiable et plus fun, c'est assurément vendeur.

Et des générations d'informaticiens ont tenté de vendre la documentation automatique, et le résultat n'a jamais été glorieux. Ma logique wue j'implémente dans le système ne peut être documentée que par moi-même.

a écrit :
Le générateur lui, se fout pas mal de savoir si celui qui appuie sur le bouton pour créer / modifier un site en Bootstrap ou en tartempion est compétent ou non.

Il devra être compétent en java et dans la maîtrise de ton générateur néanmoins.

a écrit :
Le seul niveau de compétence requis est celui du gars qui a développé ledit générateur et intégré les frameworks dans toute leurs subtilités.

La logique doit bien être codée quelque part. À moins qu'on ne parle toujours que de site statique, mais du coup je ne vois pas l'intérêt de Symfony, Drupal ou Wordpress là-dedans.

kustolovic a écrit :
Pour ma part je peine vraiment à comprendre l'intérêt avec les frameworks.

Tes arguments sont pertinents, mais il me semble qu'ils reposent sur une approche erronnée du générateur tel qu'il est conçu, probablement parce que je n'ai pas correctement décrit ses fonctionalités.
Il n'est en effet pas du tout question de réécrire Bootstrap, Foundation ou autre framework, qu'une armée de petites mains maintient à jour.
Lorsque je dis que le générateur intègre Bootstrap, par exemple, il s'agit bien de l'intégrer en l'état, c'est à dire dans ses différentes versions et sans modifier son code de quelque façon que ce soit.
Le principe du générateur est donc le suivant :
- je décrit une structure de page HTML "logique" (ex. je veux un jumbotron)
- je choisis Bootstrap comme framework de mise en forme
- je choisis de générer un site PHP dynamique natif
Le processus de sérialisation va être le suivant :
- récupération du code Bootstrap version V (ex. 3.3.7)
- récupération du code des frameworks dépendants (ex. JQuery) dans leur version compatible avec la version V de Bootstrap (ex. 1.12.4)
- conversion du composant jumbotron "logique" en une DIV (ou balise sémantique HTML5 puisque le générateur connaît le doctype) compatible avec la version V de Bootstrap (attributs @id, @class, etc.)
- sérialisation HTML / CSS intégrant les options sécurité (CSP, etc.) et compatible avec le jeu de caractères retenu pour le projet
C'est tout... mais, pour l'instant, je n'ai rien trouvé sur le web qui faisait ça de façon multi-cible.
Quant aux compétences Java pour développer le générateur, j'ose croire qu'après plus de 30 années de programmation (je n'ai pas débuté ma carrière en informatique) j'ai eu largement le temps de les acquérir et les faire fructifier, bien que l'on doive se remettre en question en permanence dans ce domaine pour rester dans la course.
Les utilisateurs du générateur n'auront donc besoin d'aucune compétence Java pour l'utiliser, puisque cela reste du domaine du concepteur de l'outil.
En outre, la gestion de version entre fameworks (cf. Bootstrap / JQuery) ci-dessus étant assurée automatiquement par le générateur à partir des documentations officielles, l'utilisateur n'a pas non plus à se préoccuper de toute l'arrière boutique, notamment en matière de compatibilité entre versions. Il lui suffit simplement de choisir quel framework il compte utiliser et toute la tuyauterie sera mise en place, avec les versions actualisées, en arrière plan.
Quant à la documentation automatique, pour en avoir développé plusieurs dans le milieu professionnel qui est le mien, je peux te garantir que la boîte qui m'emploie a été plutôt contente de pouvoir disposer d'un outil de rétro-analyse WBI pour une migration.
Entre les déclarations du service qui ne savait plus trop bien ce que faisait l'EAI utilisé au quotidien, et les infos très précises retournées par la documentation automatique, d'aucuns ont apprécié pouvoir calculer leur budget migration prévisionnel en ayant des bases solides (objets manipulés, nombre de lignes de code, complexité du processus, etc.).
Aller solliciter des prestataires extérieurs en vue de la migration, en disposant d'une documentation extrêmement précise, est particulièrement confortable lorsqu'il faut discuter technique et, surtout, gros sous.
Modifié par sepecat (19 Mar 2017 - 10:59)

a écrit :
- je décrit une structure de page HTML "logique" (ex. je veux un jumbotron)

Mais du coup cette partie est codé à la main par l'utilisateur final ?

Aussi ce que je ne comprend pas c'est, par exemple, l'intérêt de wordpress est d'avoir le système de template, la loop et les customs post types. Ton générateur permet d'éditer un thème comme dans wordpress ? Ou alors c'est juste la sortie html qui serait identique à celle de wordpress ? (et si oui donc la question qui tue, quel rapport avec wordpress et quel différence entre ton outil et un framework lambda)

Pour le reste certains CMS on déjà du mal à gérer leur propre montés de version donc j'ai du mal à voir comment cela pourrait être fait extérieurement avec en plus une possibilité de passer de l'un à l'autre.

Voilà, dans mon esprit tu crées juste un autre framework. Ce n'est pas un reproche mais je suis curieux sur les tenants et les aboutissants de ton projet.

Donc ce que j'ai soupçonné était fondé: Le générateur concerne principalement des sites statiques: Le créateur du site n'implémente aucune logique, il se contente de décrire les pages et le contenu.

Le générateur génère du HTML ou du php statique, je le comprends, mais ce que vient faire
des frameworks tels que Symfony, Laravel ou des CMS tels que Wordpress ou Drupal dans l'affaire me paraissent un mystère total. Fournir un site statique au travers de ces outils me semble un non-sens, pourquoi ne pas se contenter de générer un site HTML statique?

Pour devenir dynamique, le concepteur doit implémenter de la logique quelque part, en utilisant un langage de programmation quelconque, ou une interface de gestion qui lui permette de définir des comportements (ce qui est généralement très limité).

Du coup je vois dès lors la faisabilité de passer d'un système A et B, d'une version 1 à 2 très facilement, en se contentant du dénominateur commun à tous ces systèmes: le site statique. Ce que je ne comprends pas c'est l'intérêt à utiliser ces systèmes, conçus pour des sites dynamiques.

Cette question du dénominateur commun est essentielle, car elle est la faiblesse d'un préprocesseur multi-cible: Ce qu'on implémente doit être disponible sur toutes les cibles sinon le préprocesseur redevient mono-cible. Et en voulant ratisser aussi large il perd tout de même largement de son intérêt?
Modifié par kustolovic (19 Mar 2017 - 13:08)

bzh a écrit :
Mais du coup cette partie est codé à la main par l'utilisateur final ?
Aussi ce que je ne comprend pas c'est, par exemple, l'intérêt de wordpress est d'avoir le système de template, la loop et les customs post types. Ton générateur permet d'éditer un thème comme dans wordpress ? Ou alors c'est juste la sortie html qui serait identique à celle de wordpress ? (et si oui donc la question qui tue, quel rapport avec wordpress et quel différence entre ton outil et un framework lambda)
Pour le reste certains CMS on déjà du mal à gérer leur propre montés de version donc j'ai du mal à voir comment cela pourrait être fait extérieurement avec en plus une possibilité de passer de l'un à l'autre.
Voilà, dans mon esprit tu crées juste un autre framework. Ce n'est pas un reproche mais je suis curieux sur les tenants et les aboutissants de ton projet.

Rassures toi, je ne prends aucun des commentaires apportés à ce sujet comme reproche (sinon je n'aurais pas ouvert ce billet ).
S'il y a des interrogations ou des doutes sur la faisabilité technique / fonctionnelle du projet, c'est à moi de les identifier car ils correspondent très certainement à des points qu'il faut clarifier d'une manière ou d'une autre.
Concernant l'aspect "codé à la main", c'est effectivement la partie située en amont du générateur, mais via un éditeur en ligne permettant de construire les pages HTML sous forme de composants assemblés (principe peu ou prou basé sur la notion de web component, voire composants Delphi si tu connais cet EDI).
On se situe là au niveau "description logique" du projet, c'est à dire sans aucun lien avec le(s) framework(s) qui seront utilisés lors de la sérialisation.
Comme je l'indiquais précédemment, si je veux un composant de type jumbotron, je me contente d'en déposer un sur l'éditeur, de définir son titre, son contenu et son / ses boutons (eux mêmes des composants).
Pour l'instant on ne parle donc pas de Wordpress, Joomla ou autre.
A un instant T, je décide ensuite d'obtenir la représentation "réelle" de ce site web en définissant au niveau du projet :
- différents paramètres (doctype, jeu de caractères, options de sécurité, etc.)
- le ou les frameworks de présentation qui seront utilisés (ex. Bootstrap, Foundation, interne, etc.)
- le ou les frameworks de langage dynamique (ex. PHP, Java, ASP, etc.)
Si je choisis de produire un type de site web rentrant dans la catégorie CMS (ex. Wordpress, Joomla, Drupal, etc.), le langage utilisé est de facto conditionné par le CMS, puisque chacun d'entre eux est développé dans un environnement connu et contraint (PHP la plupart du temps).
On parle bien de sites dynamiques...
Toutefois, si le générateur détecte qu'aucun des composants utilisés sur les pages HTML ne requiert un langage dynamique, des options supplémentaires sont alors disponibles pour produire un site entièrement statique (ex. Jekyll, etc.).
Pour la version utilisée, dès lors que j'ai choisi une configuration de sortie, les options sont connues et sélectables. Si je choisis d'utiliser Bootstrap version 3.3.7, tous les fichiers relatifs à ce frameworks sont déjà embarqués dans l'archive Java, ainsi que leurs dépendances (ex. JQuery). Le générateur se charge de créer les liens intra pages permettant d'appeler les scripts et ressources, aux bons endroits (section HEAD ou fin de BODY), et dans le bon ordre (puisqu'il existe des dépendances).
Ceci est bien entendu transparent pour l'utilisateur.
Côté SGBD, le générateur dispose d'une description des tables / champs requis, ainsi que des paramètres de connexion en environnement de DEV et en environnement de PRD. Les infos correspondantes sont dès lors automatiquement adaptées dans le flux en sortie.
Lorsque tu t'interroges sur le fait que la sortie Wordpress depuis le générateur soit identique à celle réalisée depuis un Wordpress original, tu n'es pas éloigné de la réalité puisque le but du jeu au travers du générateur est bien de dégager du temps pour se consacrer à la conception "logique" du site et obtenir ensuite un produit conforme aux normes et spécifications requises pour le framework choisi.
On peut donc penser, a priori, que cela ne présente aucun intérêt, puisqu'il suffit alors de partir d'un Wordpress installé et basta.
Oui... mais non.
Le générateur te décharge :
- de l'installation d'un Wordpress + SGBD (il est capable de le recréer ex nihilo dans une version donnée)
- d'apprendre ce CMS (après tout, un jumbotron reste un jumbotron, qu'il soit visible via Wordpress, Joomla ou tout autre environnement)
- de gérer les dépendances entre fichiers (ceux qui auront eu à modifier des noms de variables / fonction dans tout un projet sauront de quoi je parle...)
- etc.
Quid du "templating" ?
Le générateur peut importer des modèles existants ou à venir puisque, de toute façon, les règles de nommage / accès sont connues pour un CMS donné.
A terme, il est par ailleurs prévu d'intégrer un module de création de modèles directement dans le générateur.
Voici donc quelques explications et précisions complémentaires qui pourront probablement t'aider à mieux cerner le but recherché. Dans l'immédiat, il est exact que cet outil peux paraître pour le moins ésothérique car pas forcément facile à décrire et expliciter dans ses moindres détails.
J'intègre en ce moment Bootstrap dans le générateur afin de pouvoir mettre en place prochainement un portail web statique décrivant par le détail chaque module / fonction et leur finalité.
Portail bien évidemment réalisé en Bootstrap, histoire de démontrer la faisabilité du processus et obtenir en retour des critiques (constructives ?) de la part des pros dudit Bootstrap pour corriger / améliorer l'outil.
Côté développement, cela fait déjà un an que j'investis dans ce projet et le temps restant encore à y consacrer peut, raisonnablement, être estimé à deux, voire trois ans.
Pil, poil pour mon départ en retraite...

kustolovic a écrit :
Donc ce que j'ai soupçonné était fondé: Le générateur concerne principalement des sites statiques: Le créateur du site n'implémente aucune logique, il se contente de décrire les pages et le contenu.

Bin non... hélas.
Le générateur est bien prévu pour produire des sites web statiques et/ou dynamiques.
Dans la mesure où je viens de faire une réponse plutôt longue au précédent commentaire de BZH, je ne vais pas alourdir le forum avec une nouvelle tartine sur le sujet.
Par contre, les retours que vous faites sur ledit sujet sont très intéressants et me permette de voir quels sont les aspects de l'outil qui posent problème, vu de l'extérieur.