En ce sens qu'à moins d'apporter des modifications ou des ajouts particuliers à l'application, on ne modifie jamais un modèle de données. Et en l'occurrence, je ne sais pas si tu as quand même regardé la structure de données que j'ai suggéré plus haut, mais tu aurais un modèle largement plus sain et inamovible quel que soit le nombre de langues.

Autre point : ajouter une langue dans un fichier de conf, ça voudrait dire ajouter les traductions : là, avec un ajout de colonnes dynamique, ça veut dire que par défaut les colonnes sont vides ou encore valent NULL en attendant les mises-à-jour. Encore une fois, avec la structure proposée, pas (ou vraiment très peu) de valeurs NULL dans la structure, et si ce détail fait quand même partie des bonnes pratiques en modélisation de base de données, ce n'est peut-être pas uniquement pour faire joli dans une conférence.

Enfin bon, pour ce que j'en dis hein, si ce truc fait ton bonheur, tu m'en vois ravi, pour ma part je ne m'en servirai jamais, mais je m'en voudrais de te priver de ce plaisir

Je comprends ton point de vue, mais je pars du principe que si un individu dit que son site sera en anglais, français et espagnol, ce n'est pas pour laisser les titres des pages ou les méta-description vides dans une langue (car la table ici concernée est celle des pages).
En tant que développeur, je préfère largement avoir une table ou tout est lisible directement dans phpmyadmin, comme ça si il y a un problème, je debug plus vite si je dois mettre les mains dans le cambouis plutôt que de me demander ou sont les associations d'ids. C'est ce qui a justifié ce choix de schéma pour les pages.

Ça part d'un raisonnement un peu barbare c'est vrai, je sais qu'il est recommandé de factoriser au plus les tables mais quand je vois la structure de données de certains produits (par exemple celle de magento), je me dis que ce systématisme appliqué sans réel motif alourdit le schéma sans raisons valables. Pour moi nos 2 schémas dans leur contexte d'utilisation se valent, c'est juste qu'il y en a un qui est plus académique car plus factorisé et l'autre plus lisible par un humain.

Je trouve le terme "aberration technique" un peu fort. Non conventionnel ok

Pas d'accord.

On ne développe pas pour les développeurs mais pour les utilisateurs en tout premier lieu. La structure des tables est peut-être plus facile à lire pour un humain de ta manière, je suis bien disposé à te l'accorder (enfin plus facile humainement si tu te limites à des requêtes du type SELECT * sur une seule table), mais dis-toi que le SGBD le lit mille fois mieux et plus vite que nous tous réunis et il est fait pour ça, c'est une question d'efficacité. Ok, ça veut dire qu'il faut pour le développeur se creuser un poil plus les méninges. Woaw, faut travailler, c'est terrible comme épreuve, et en plus il faudrait faire des requêtes SQL avec des jointures, vite un verre d'eau et ouvrez la fenêtre je vais étouffer !

Et puis ne me dis quand même pas que le schéma que j'ai suggéré est vraiment hyper-complexe. On est très loin de Magento que tu as cité avec, de mémoire, ses 400 tables et des poussières, là je te l'accorde aussi, rentrer dedans demande un peu plus qu'une poignée de main et pas mal d'analyse. Mais c'est pourtant efficace. Essaye d'imaginer le modèle de données de Magento avec ta manière de faire : là, ce serait une usine à gaz infernale.

Vois un petit peu à long terme aussi : si ton application évolue et voit au fil du temps se rajouter des éléments divers et variés impliquant l'ajout de nouvelles tables, chaque fois qu'un de ces éléments devra gérer des problèmes linguistiques, tu vas faire comment : rajouter des colonnes aussi dans les nouvelles tables ? Bonjour la maintenance : il faudra aussi mettre à jour ton système d'ajout de colonnes automatisée... pas terrible ça

Je trouve le terme "aberration technique" un peu fort. Non conventionnel ok

J'ai un jour été qualifié sur ce forum par un illustre admin de « méticuleur de mouches » : j'assume complètement et je m'en porte aussi bien. Je code comme ça et mes montages tiennent la route pendant des années sans que j'aie besoin de revenir dessus.

Enfin bon, si ça peut te consoler, j'ai déjà vu très largement pire : un gugusse dans une application de commerce en ligne de grande distribution connue en France avait trouvé le moyen de me créer une table pour enregistrer les civilités : dedans, trois lignes de données pour « Monsieur », « Madame » et « Mademoiselle ». Comme je venais d'arriver dans l'équipe, je ne l'ai pas étranglé tout de suite, finalement mes suggestions ont porté leurs fruits et il y a eu des modifications plus que bienvenues.

J'ai l'impression qu'on pourrait discuter pendant des heures sans que ça nous mène quelque part. Tu as une vision arretée sur la manière de modéliser, et dans ma vision tout se fait au cas par cas.
La maintenance ne pose pas de problème, le framework est conçu avec un ORM. A priori, le développeur n'a même pas besoin de savoir comment les tables sont créées.
L'impact sur les performances d’intégrer les contenus de langue dans la même table est à priori positif, il n'y a qu'une seule requête à effectuer dans mon modèle contre 4 dans le tien

La maintenance ne pose pas de problème, le framework est conçu avec un ORM.

Mais précisément : la présence d'un ORM justifie d'autant moins un montage barbare du modèle de données, en tous cas c'est une question de cohérence de raisonnement il me semble.

Alors en y réfléchissant un peu, j'en suis venu à envisager un problème de terminologie supplémentaire : lorsque tu parles des développeurs appelés à utiliser ton outil, fais-tu référence à des développeurs ou à des intégrateurs. La nuance a son importance : soit on a affaire à un intégrateur, il sait plus ou moins programmer et au moins lire à peu près du code mais il ne rentre jamais très profondément dedans, son cœur de métier consistant surtout à implémenter une interface graphique personnalisée et à configurer l'activation de tel ou tel module, comme il ferait avec n'importe quelle plateforme de blog. Soit on a affaire à un développeur qui crée des modules, rentre dans le code et étend des classes pour les besoins de fonctionnement du module qu'il crée, voire même il contribue en améliorant tel ou tel aspect du code de l'application : le premier n'a effectivement ni très envie ni vraiment besoin de connaitre les mystères de la base de données qui est derrière, le second en revanche doit pouvoir en exploiter toutes les subtilités et donc en comprendre le modèle.

Mais même s'il y a un ORM, ça ne peut en aucun cas dispenser le développeur d'avoir un minimum de connaissance de la structure des données de l'application, c'est même un pré-requis indispensable. Comme en outre ton ORM n'est ni Doctrine ni Propel mais un montage maison, il sera peut-être moins lourd et moins abouti, présentant de ce fait certains manques techniques et ne vois là aucun reproche en la matière, construire un ORM, ce n'est pas précisément simple et ça ne se crée pas d'un claquement de doigts : le développeur qui a besoin d'extraire certaines données d'une certaine manière doit et préfèrera sans aucun doute pouvoir compter sur l'ORM bien sûr, mais il doit aussi pouvoir en palier les lacunes techniques en attendant une mise à jour et écrire lui-même certaines de ses requêtes SQL. La conséquence est simple, si le modèle de donnée répond à des critères de standards un peu stricts, il sera d'autant plus facile d'y contribuer, autrement, c'est la porte ouverte à d'autres barbaries auxquelles je n'ose même pas penser

L'impact sur les performances d’intégrer les contenus de langue dans la même table est à priori positif, il n'y a qu'une seule requête à effectuer dans mon modèle contre 4 dans le tien

C'est un raisonnement plus que faux. Il faut compter bien plus de critères que la simple requête pour parler de performances.
Un SGBD fait bien des choses, notamment il gère les index pour un accès rapide, et c'est ce qui va bouffer ton modèle par rapport à celui de Cyrano.

Salut moogli, merci beaucoup d'avoir passé du temps dessus, j'aurai souhaité réagir plus vite.

Beaucoup de tutoriaux ne correspondent plus exactement à la version actuellement en téléchargement car sur les forums de developpez.net on m'a donné beaucoup de conseils pour réécrire le noyau.

Je suis surpris que l'install marche pas je l'ai testé dans pas mal d'environnements différents et j'ai minimisé les options pour éviter au maximum les plantages, tu peux me donner un descriptif de ton environnement de dev pour que j'essaie de reproduire l'erreur ? La table ufm__pages est vide ?

je n'ai pas réessayé depuis, mais oui la table est crée mais vide.

dommage que les tutos ne soit pas a jour :/

Même si la version, n'a pas l'air d'avoir changée, j'ai re dl l'archive et même chose.

Aujourd'hui je test sur php5.4 alpha 3 et mysql 5.5.11 le tous avec un apache 2.2 sous win 7 ultimate

J'ai testé sur un vm winxp apache, php 5.3.5 et mysql 5.5.8 et même pas de table créer, je reste sur la page de conf, quand j'essai l'admin j'ai ce message d'erreur :
Warning: preg_match() [function.preg-match]: Compilation failed: PCRE does not support \L, \l, \N{name}, \U, or \u at offset 17 in C:\xampp\htdocs\ufm\framework\phpExternals\clearbricks\url.handler\class.url.handler.php on line 143

:/

@+

Je sais xTG, j'ai un peu dit ça pour provoquer ^^.
Parce qu'il faut être pragmatique dans la vie j'ai effectué un protocole de test avec le modèle proposé par Cyrano et le mien sur le serveur suivant

PhP 5.3.5, MySQL 5.1.36, Apache 2.2.11

J'ai testé les 2 modèles dans des conditions critiques : 5 langues et 100 pages (au sens du framework ufm, ce qui correspondrait à 100 classes contrôleurs dans un framework MVC standard type Codeigniter).
Toutes les tables ont été remplies avec des des identifiants aléatoires. Les mots aléatoires sont composés de chaines de caractères comprises entre 5 et 10 lettres prises au hasard. Les phrases comportent 15 mots aléatoires.

Après 10 tests effectués avec un nombre d'itérations aléatoires (entre 100 et 1000) pour éliminer le biais j'en arrive à un temps d’exécution moyen pour 100 itérations

Pour mon modèle de base : 480.29279708862 ms
Pour le modèle de cyrano : 448.28605651855 ms

Soit une vitesse d’exécution plus rapide de 7% dans des conditions critiques.
---

En conclusion je vais modifier la manière dont le framework récupère les contenus multilangues en base quitte à ce qu'elles soient plus difficiles à lire pour un humain.

moogli je vais préparer une nouvelle version des que possible, normalement il n'y a plus de dépendance à clearbricks dans le framework

moogli, est-ce que tu peux essayer avec cette version http://ufm.erraprod.com/__files/ufm_fra ... er0.91.zip et me dire ce que tu obtiens ?

Merci d'avance !

@moogli visiblement ton PCRE n'est pas compiler avec le support de l'utf-8

@moogli visiblement ton PCRE n'est pas compiler avec le support de l'utf-8

surement j'ai pas cherché j'ai simplement pris la dernière version de Xampp et je ne pense pas qu'il se fasse une compilation perso ?

moogli, est-ce que tu peux essayer avec cette version http://ufm.erraprod.com/__files/ufm_fra ... er0.91.zip et me dire ce que tu obtiens ?

Merci d'avance !

j'ai un gros logo vert et blanc avec des mot en anglais qui disent que c'est bon (php5.4a3)
et création de deux tables test_table et ufm__pages avec 1 enregistrement chacune

coté fonctionnalité tu pourrais laisser le choix de la langue par défaut dans le formulaire au départ

par contre quand je vois des <?= (dans le code des pages) la par contre j'ai peur, car perso c'est LE truc que je désactive par défaut les short tags c'est pas une conf pérenne. Bon après j'ai pas regardé ta moulinette, s'il y a des modif du code des transformations quelconque dont la suppression des short tags pourquoi pas

du coup j'ai voulu tester les autres tutos :
http://ufm.erraprod.com/fr/tutorials/install_template/ : parle d'une archive mais pas de lien
d'ailleurs un p'tit htmlentities sur les entrées html éviterais de ne pas tous voir dans le tuto
par exemple : Vous devriez donc avoir quelque chose comme $res = '';
devrait être
Vous devriez donc avoir quelque chose comme $res = '<!DOCTYPE html PUBLIC...............</html>';
d'après le code source.

sur la page par défaut (configuration de la page)le bouton "+" ne fonctionne pas (IE, firefox et chrome), par contre le supprimer fonctionne trop bien on peu virer la page par défaut mais quand c'est la seule
et dans ce cas

Warning: Invalid argument supplied for foreach() in H:\web\docRoot\test\ufm\framework\phpUFM\System\UFM.System.UPageBuilder.php on line 340
Warning: Invalid argument supplied for foreach() in H:\web\docRoot\test\ufm\framework\phpUFM\System\UFM.System.UPageBuilder.php on line 346
Warning: file_get_contents(H:\web\docRoot\test\ufm\application\templates\application.templates.): failed to open stream: No such file or directory in

impossible d'ajouter des vue depuis l'interface faut forcément faire les fichiers à la main en dehors ?(idem template) donc je peux même essayer de réparer ma connerie du point précédent

pour ce qui est de l'installation d'un template pré fait c'est complexe une page permettant le téléchargement serait plus simple, d'ailleurs une permettant la création (voir création a partir d'un existant) serait le must.

tu indique dans ton premier message pas de "language de templating" que tu html, effectivement pas les "templates" bien qu'il y ai du code php obsucure réclament de connaitre le fonctionnement du frameworks (bon ça c'est pour tous tu me dira).

par contre dans les vues (qui doivent représenter le rendu final ? d'ailleur je pige pas la différence entre vu et template. il n'y a pas que du html, d'ailleurs s'en ai ?

<center><?=__('Change language')?><a href="<?=WEBROOT?>/en"><?=CLocale::flag('gb')?></a>
 <a href="<?=WEBROOT?>/fr"><?=CLocale::flag('fr')?></a> </center>
<!-- Object call is easy and made through a factory. Flags (SQL|CREATE) means the system will first try to get the field
 from SQL, and if its not possible, the system will create a new one. There are 3 flags possible (SESSION, SQL, CREATE) -->

<?
$sample_object = Factory::getFieldObject('sample_object', 'sample_object', 'SQL|CREATE');
echo $sample_object->toFormEditInPlace('Controller_Admin/saveAjax');
echo phpinfo();
?>
<!--  The editInPlace mode allows you to see the field as the end user would see it and change data by clicking on it
This is allowed by the FIELD model and dramatically speeds up content creation and modification
Check the phpUFM/Fields/Base/UObject class to see the different modes -->

<include src="application.views.subview.home_include.tpl"></include>

au final, je pense qu'il a surement de bonne a faire avec tous ceci, mais l'apprentissage, pour moi (je ne parle pas pour les autres), n'est pas possible. Du fait de la doc que je ne comprend pas toujours et pas forcement complète (exemple du lien au dessus).

je ne vois pas trop la rapidité de l'utilisation de mon point de vue, en dehors d'un copier collé de l'appli et deux trois modif simple ?

@+


la je ne vois pas trop

Cool que tu aies pu l'installer

Les shorts tags <? et <?= fonctionnent même si ils ne sont pas activés sur le seveur, le "parseur" de vues les remplace par des tags corrects php. J'ai mis ça en place pour rendre plus lisible les vues et les templates.

Les tutos de templating ne sont plus vraiment à jour, le coup du $res = .... est abandonné tu peux mettre directement du code html a l’intérieur des templates et des vues

- Ok je vais protéger la suppression des pages pour éviter ce problème.
- Pour l'ajout des vues et les templates oui il faut créer pour le moment le fichier mavue.tpl à la main.
- Les templates et les vues sont strictement identiques
- Je manque un peu de temps, il faut que je débloque 20/30h pour faire des tutoriaux clairs avec la conception de 2 applis références car entre mon premier post et la version que tu testes il y a beaucoup de choses qui ont changé.

L’intérêt de rapidité ne peut être mis en évidence qu'avec un tuto de création d'appli standard style blog

Quand tu dis

pour ce qui est de l'installation d'un template pré fait c'est complexe une page permettant le téléchargement serait plus simple, d'ailleurs une permettant la création (voir création a partir d'un existant) serait le must.

tu veux dire quoi exactement ?

Les shorts tags <? et <?= fonctionnent même si ils ne sont pas activés sur le seveur, le "parseur" de vues les remplace par des tags corrects php. J'ai mis ça en place pour rendre plus lisible les vues et les templates.

Ce qui signifie en d'autres termes que tu insères un système intermédiaire qui doit d'abord parser le PHP avant de l'envoyer à l'interprétation, tout ça pour économiser l'écriture de trois caractères ??? Pas sûr que le gain de performances soit très évident sur ce coup là

C'est un peu plus vicieux que ça en fait, les fichiers .tpl que tu créé (qui sont de l'html avec injection de tags php/shorts tags et quelques tags proprietaires style <zone name="footer"></zone>) sont interprétés avec par le parseur et transformés en fichiers .tpl.php qui eux sont lisibles directement.

L'utilisateur/client va lui lire directement le fichier .tpl.php, l’interpréteur tpl->tpl.php n'est exécuté seulement si le fichier .tpl.php n'existe pas ou si tu es en mode développeur. Au début j'avais mis un système de vérification par date (si la variable de date contenu dans le fichier .tpl.php est antérieure à la date du fichier mère .tpl on le régénère) mais ça faisait trop de vérifications.

Les shorts tags <? et <?= fonctionnent même si ils ne sont pas activés sur le seveur, le "parseur" de vues les remplace par des tags corrects php. J'ai mis ça en place pour rendre plus lisible les vues et les templates.

Ce qui signifie en d'autres termes que tu insères un système intermédiaire qui doit d'abord parser le PHP avant de l'envoyer à l'interprétation, tout ça pour économiser l'écriture de trois caractères ??? Pas sûr que le gain de performances soit très évident sur ce coup là

je plussoie fortement...