Bonjour,

Je découvre Jelix et trouve cette solution intéressante. Cependant quelque chose me gène et pourrait bien compromettre mon utilisation de ce framework.

J'ai cherché mais l'axe ORM est toujours : BDD -> XML -> DAO Jelix Ceci est une approche intéressante mais dans certains cas, il est primordial de pouvoir faire du : PHP -> XML -> BDD ; en gros générer le SQL à partir des classes.

Presque tous les frameworks proposent ça en passant par une ligne de commande

Pourquoi pas Jelix ?

Bonjour,

je n'ai pas compris vos "cheminements" (php->xml->bdd / bdd->xml->dao) mais si vous vous demandez pourquoi Jelix ne génère pas de SQL à partir des classes, hé bien il génère bien du SQL (en cache) à partir de classes jDao, interprétant le XML.

Par contre, non il n'y a pas de génération de SQL à partir de classes "Modèle".

Pour la 1.2 par contre il y a en préparation le support de Doctrine pour ceux qui souhaiteraient.

Bonjour,

je n'ai pas non plus compris ce que tu entends par BDD -> XML -> DAO ou PHP -> XML -> BDD. Peux tu préciser ?

je me suis surement mal exprimé et m'en excuse.

En fait, je parlais bien de pouvoir générer le sql à partir des modèles de classes.

 De mon expérience personnelle, je n'ai jamais reussi à établir de règles de construction d'un projet. Il me semble qu'il faut des fois partir de la BDD pour générer le code mais dans certains cas l'inverse est un meilleur choix. (ex : héritage multiples .....).

Doctrine est une solution intéressante mais j'espère que Jelix ne va pas petit à petit devenir un symfony , à mon sens, trop lourd , trop restrictif.

Concernant a 1.2, elle sera disponible à quelle date (environ) en version stable ???

j'en profite pour amener d'autres questions :

• a quand une commande console pour générer les manipulations en BDD. un "installer" a diffuser entre dev d'un meme equipe pour toujours avoir la meme bdd.
• un scaffold performant pour reduire le temps de dev de certains formulaire classique

merci encore à vous de votre reactivité et de ce beau produit

Antho

Bonjour,

ouiserval a dit :
En fait, je parlais bien de pouvoir générer le sql à partir des modèles de classes.
De mon expérience personnelle, je n'ai jamais reussi à établir de règles de construction d'un projet. Il me semble qu'il faut des fois partir de la BDD pour générer le code

ceci est le cas avec jelix et les DAO

mais dans certains cas l'inverse est un meilleur choix. (ex : héritage multiples .....).

... mais pas le cas de jelix, ce qui n'empeche pas d'avoir tout de meme des classes models/metiers efficaces faites "main"

Doctrine est une solution intéressante mais j'espère que Jelix ne va pas petit à petit devenir un symfony , à mon sens, trop lourd , trop restrictif.

Doctrine ne remplacera pas, il sera un apport supplémentaire pour qui veut aborder jelix avec son framework ORM

Concernant a 1.2, elle sera disponible à quelle date (environ) en version stable ???

réponse de normand : quand elle sera prête :)

j'en profite pour amener d'autres questions :

- a quand une commande console pour générer les manipulations en BDD. un "installer" a diffuser

pour l'heure ya pas

entre dev d'un meme equipe pour toujours avoir la meme bdd.

pour ca un SCM suffit non ?

- un scaffold performant pour reduire le temps de dev de certains formulaire classique

ya deja avec le CRUD.

Salut,

Avec jelix, on ne génère pas le sql comme tu l'entends (tu veux parler en fait du schema sql c'est ça ?). avec jDao, on créer d'abord la base, les tables, les contraintes etc, et ensuite on peut générer automatiquement avec jelix les fichiers daos. En effet, les méthodologies de conceptions les plus courantes (même si elles sont moins souples par rapport à des methodes plus récentes), on créer un cahier des charges, on réalise un modele de conception de données (MCD), souvent par le biais de logiciels adéquates, qui ensuite souvent permettent de génèrer automatiquement le schema sql. Il y a aussi ceux qui préfèrent créer directement (via phpmyadmin ou autre) les tables dans la base. Bref c'est pourquoi, historiquement, avec jDao, on génère les dao à partir du schéma et non l'inverse.

Une autre raison, c'est qu'en général, les outils qui génèrent le schema sql à partir d'une classe php ou un fichier xml, ne produisent pas forcément un schema optimisé. Ils ne vont par exemple pas forcément créer les index sur les champs qu'il faut pour optimiser certaines requêtes. Ou alors peut être permettent-t-il d'indiquer les informations qu'il faut, mais alors c'est coté php que ce n'est pas performant. En effet, ces informations sont souvent inutiles pour l'exécution du code php, le la bilbiothèque ORM, du framework. ça occupe donc pour rien, au choix, du temps processeur, de la mémoire etc...

Note que jDao par contre, à partir des informations dans le fichier XML, génère les requètes SQL et les inscrit en dur dans la classe générée correspondant au dao, cette classe étant mis en cache. Cela évite à jDao, contrairement à beaucoup d'autres ORM, de devoir générer la requête à chaque appel (liste des champs dans le SELECT par ex).

Doctrine est une solution intéressante mais j'espère que Jelix ne va pas petit à petit devenir un symfony , à mon sens, trop lourd , trop restrictif.

Foxmask a un plugin en préparation pour pouvoir utiliser Doctrine dans Jelix, pour ceux qui trouvent jDao trop peu souple (il a c'est vrai quelques lacunes, mais il est prévu de l'améliorer dans le futur).

Concernant a 1.2, elle sera disponible à quelle date (environ) en version stable ???

la beta est quasi prête. En fait il ne reste plus qu'à finir de compléter le manuel, ce que j'essaie de faire le plus rapidement possible. La version finale suivra la beta assez rapidement, vu le retard que l'on a sur le planning. J'espère la sortir en juin. En attendant, faut pas hésiter à tester la nightly, pour rapporter le maximum de bug.

a quand une commande console pour générer les manipulations en BDD. un "installer" a diffuser entre dev d'un meme equipe pour toujours avoir la meme bdd.

Je ne sais pas ce que tu entends par manipulation en BDD. c'est vague comme terme, "manipulation". un client comme phpmyadmin ne suffit pas ?

Et sinon la 1.2 comportera tout un système d'installation et de mise à jour automatique de module. Il suffira donc d'ajouter dans un répertoire install/ d'un module, des scripts php (avec un nom spécifique), qui se chargeront de faire les modifications dans la base ou ailleurs pour chaque version. Ensuite, pour mettre à jour une application (entre plusieurs dev par ex), il suffira de mettre à jour les sources de l'application, et d'executer ensuite une seule commande jelix.php installapp pour mettre à jour le reste (la base etc), pour peu qu'on ait donc écrit ces scripts php de mise à jour. Le système fonctionne déjà dans les nightlies.

un scaffold performant pour reduire le temps de dev de certains formulaire classique

Il y a déjà une commande jelix pour créer un formulaire à partir d'un dao, et même tout un controleur CRUD à partir d'une table existante (cela te gènere le dao, le fichier jforms, et le controleur). Si tu penses que l'on peut encore faire mieux, n'hésite pas à nous faire part de tes idées.

merci encore à vous de votre reactivité et de ce beau produit

merci :-)