Objectif:

On voudrait, par exemple, générer un objet php à partir d'un dao qui serait lui même un objet, au lieu d'être un fichier xml.

Interêt:

• Bénéficier de la puissance du compilateur de Jelix sans être obliger de définir de fichier source.
• Concevoir un système de génération d'objets qui permettrait à un non developpeur de faire son propre cms en utilisant au mieux la puissance de jelix, grâce à jCompiler.

Necessité de modifier jSelector

• Possibilité qu'un selecteur ne pointe pas necessairement vers un fichier source

(dans ce cas, plus de test de date entre le fichier compilé et sa source)

• Possibiliter de transmettre un paramètre objet pour compiler le fichier. En effet, s'il n'y a plus de fichier source, il doit tout de même y avoir quelque chose à compiler...

(dans ce cas, il faudrait compiler le fichier avant toute utilisation : à l'installation, dans la zone d'admin, ou lors de l'ajout d'un plugin spécifique ajoutant des propriétés à l'objet par exemple...)

Les modification de jSelector ne prennent que quelques lignes. J'ai tester, ça fonctionne bien.

Un plugin jCoordinateur ne semble pas permettre de cours-circuiter une modification de jSelector. Je suis donc bloqué si je veux respecter le projet Jelix tout en developpant proprement ce système. D'où cette proposition de modification.

A débattre...

Je me suis tromper de section dans le forum. Ce message devrait être dans contribution. Désolé.

Salut,

Je ne comprend pas ce que tu veux faire

générer un objet php à partir d'un dao qui serait lui même un objet

Qu'entends tu par générer ? Pourquoi faudrait-il "générer" un objet à partir d'un autre objet ? Que faudrait-il générer exactement ? Est ce que la simple instanciation du dao objet ne suffirait pas ?

Pour instancier un dao, on doit, pour l'instant pointer vers un fichier source en XML. Je souhaiterais simplement que la déclaration puisse se faire via un objet php plutôt qu'un fichier source xml.

Ma proposition porte, pour le moment, de manière générale, sur le fait qu'un selecteur oblige l'existence d'un fichier source. Or on peut très bien souhaiter compiler quelque chose sans avoir besoin de fichier de definition en XML. En effet ces fichiers sont des données statiques. Si l'on souhaite dynamiser la définition d'un objet à compiler, on est coincé.

L'idée consiste à pouvoir transmettre au compilateur un paramètre supplémentaire. Ce paramètre serait un objet de définition en php, et non un fichier source en xml. Le selecteur pointe alors uniquement vers un fichier compilé. Une compilation préalable (en zone d'admin par exemple) est alors necessaire.

Pour ce faire,d'après mes tests, je crois me souvenir qu'il faut simplement (je n'est pas accès à mon travail d'où je suis) : Ajouter le parametre $def=false à la methode compiler d'une interface de Jelix. compiler($src,$def=false) Si $def n'est pas égale à false, on ne teste pas la différence de date entre un fichier source (inexistant) et un fichier compilé (necessairement présent avant l'instanciation). Dans ce cas, la compilation de l'objet doit être prévue par le developpeur, et le contenu de l'objet instancier dépend du contexte de compilation précedent.

Une compilation est requise. Par exmple, pour jDao, il suffit de creer une nouvelle méthode compiler($selector,$definition); où $selector ne correspond en amont à rien du tout, mais à l'adresse du futur fichier compilé.

J'avoue ne pas te suivre. Si tu fourni une classe PHP plutôt qu'un fichier XML, je ne vois pas ce qu'il y a à "compiler". Il suffirait que jDao fasse une simple inclusion.

Pour instancier un dao, on doit, pour l'instant pointer vers un fichier source en XML. Je souhaiterais simplement que la déclaration puisse se faire via un objet php plutôt qu'un fichier source xml.

Oui et donc, jDao chercherait un *.dao.xml ou un *.dao.php. Selon le cas, il compile ou il inclus.

Ma proposition porte, pour le moment, de manière générale, sur le fait qu'un selecteur oblige l'existence d'un fichier source.

que ce soit un fichier php ou un fichier xml, ça ne change donc rien.

Or on peut très bien souhaiter compiler quelque chose sans avoir besoin de fichier de definition en XML

compiler quoi ? Actuellement, jDao ne fait que créer deux classes à partir du fichier XML. Si tu veux fournir directement ces classes (héritant de jDaoRecordBase et jDaoFactoryBase), pourquoi pas, mais alors il n'y a pas de phase de compilation, puisque c'est du php ce que tu fournis et que il te suffirait d'indiquer dans les bonnes propriétés de ces classes le descriptif des champs, et de créer tes méthodes avec tes propres requêtes SQL.

Ou alors que contiendrait cette classe ?

En effet ces fichiers sont des données statiques. Si l'on souhaite dynamiser la définition d'un objet à compiler, on est coincé.

Dynamiser à quel niveau ? à priori, la structure d'une table change rarement durant la vie d'une appli.

Et sinon, actuellement, il y a toujours moyen de modifier un fichier dao à la volée. Le système d'overload est fait pour ça. Suffit que tu modifie/génère à la volée un fichier dao xml dans le répertoire des overloads, et c'est bon ;-)

Si maintenant tu cherches plutôt à remplacer dao par des classes métiers plus complexes, fait une classe métier, et tu les appelles avec jClasses (et ces classes peuvent faire appel aux daos pour les trucs les plus simples).

laurentj a dit :
Oui et donc, jDao chercherait un *.dao.xml ou un *.dao.php. Selon le cas, il compile ou il inclus.

Non, pas de fichier du tout justement.

Ma proposition porte, pour le moment, de manière générale, sur le fait qu'un selecteur oblige l'existence d'un fichier source.

que ce soit un fichier php ou un fichier xml, ça ne change donc rien.

L'idée ce serait qu'il n'y ai plus besoin de fichier pour la compilation. Que l'on puisse transmettre autre chose à la place. (un objet ou une variable tableau par exmeple)

Or on peut très bien souhaiter compiler quelque chose sans avoir besoin de fichier de definition en XML

a
compiler quoi ? Actuellement, jDao ne fait que créer deux classes à partir du fichier XML. Si tu veux fournir directement ces classes (héritant de jDaoRecordBase et jDaoFactoryBase), pourquoi pas, mais alors il n'y a pas de phase de compilation, puisque c'est du php ce que tu fournis et que il te suffirait d'indiquer dans les bonnes propriétés de ces classes le descriptif des champs, et de créer tes méthodes avec tes propres requêtes SQL.

Ou alors que contiendrait cette classe ?

C'est presque ça l'idée, sauf que je ne souhaite pas recreer mes propres methodes. En fait je pense à un objet voire une variable tableau dont la structure déclarative serait aussi simple que le fichier XML actuel.

En effet ces fichiers sont des données statiques. Si l'on souhaite dynamiser la définition d'un objet à compiler, on est coincé.

Dynamiser à quel niveau ? à priori, la structure d'une table change rarement durant la vie d'une appli.

Ca dépend comment on conçoit son appli. Drupal par exemple Si je souhaite faire un genre de système de plugin qui ajoute des fonctionnalitées à un objet, la structure change.

Et sinon, actuellement, il y a toujours moyen de modifier un fichier dao à la volée. Le système d'overload est fait pour ça. Suffit que tu modifie/génère à la volée un fichier dao xml dans le répertoire des overloads, et c'est bon ;-)

Si j'overload, je remplace la structure. Je n'ajoute pas de propriété... Au bout de 2 plugins souhaitant ajouter des fonctionnalitées à un même objet, la stratégie ne tient plus. C'est l'un ou l'autre. A moins que je me trompe... Mais en lisant les lignes de code je n'ai pas vu de "mixage" d'overload de daos dans le compilateur... Ce qui d'ailleurs ne serait pas souhaitable. Ce ne serait plus des overloads, mais autre chose...

Si maintenant tu cherches plutôt à remplacer dao par des classes métiers plus complexes, fait une classe métier, et tu les appelles avec jClasses (et ces classes peuvent faire appel aux daos pour les trucs les plus simples).

En fait l'interêt d'utiliser le compilateur, c'est simplement la performance. Et l'interêt d'utiliser une variable tableau ou un objet pour la déclaration du dao c'est pour simplifier au maximum l'écriture des plugins grâce à la puissance du compilateur de Jelix. Je fais un shéma ?

J'ai tester ça fonctionne bien! Je ne pointe plus vers un fichier. Je reste cependant encore sur du XML... J'ai cloné jDao, j'en ai fait un plugin jcoord mais j'ai du modifier jIncluder pour qu'il permette de transmettre à jCompiler autre chose qu'un selecteur, à savoir la déclaration à l'état brut. Dans le cas où cette déclaration (objet ou tableau, qu'importe) est transmise, jIncluder ne doit plus tester la différence de date entre une source et la compilation, puisqu'il n'y a pas de source. Il se contente alors de vérifier que le fichier compilé existe ou renvoie une exception. La compilation doit en outre être effectuée en amont par le "système de gestion de plugins"...

Je pourrais très bien écrire un compilateur sous forme de classes metiers, mais 95% du code serait alors copié collé à partir des classes Jelix. Ce qui me pose un gros problème quand au respect du principe de developpement visant à factoriser au maximum...

En fait, c'est le principe de drupal qui permet d'ajouter ou d'enlever des champs, mais sans surcouche. Tout serait compilé ou recompilé zone d'admin lors de l'installation ou de la désinstallation d'un plugin.

Pour ajouter une colonne à une table, un plugin n'aurait qu'à ajouter une ligne dans un tableau php (ou objet) dont la description serait aussi simple que dans un dao.xml.

Rien ne t’empêche de faire ca avec le système overloads je pense.

A l'installation du module, tu dupliques le dao dans l'overload si nécessaire, ensuite tu ajoutes ton ou tes champs dans le dao. Au final, tu seras content car ton champ est présent dans le DAO et en plus tu t'es pas amusé à modifier le fonctionnement actuel :D

A la désinstallation du module tu pourrais même retirer les champs que tu as rajouté a l'installation.

Litchi a raison, on peut faire de cette manière.

Il suffirait d'ajouter une methode quelque part (jDao par exemple, ou mieux créer un nouvel objet jDaoModifier), qui permet d'ajouter une propriété dans un dao. Cette méthode duplique alors le dao dans l'overload si il n'existe pas déjà, et ajoute la propriété en question. On ne touche pas alors à tout le processus qu'il y a derrière.

jDaoModifier serait principalement utilisé dans les scripts d'install de module du nouveau système d'install de la 1.2.

laurentj a dit :

jDaoModifier serait principalement utilisé dans les scripts d'install de module du nouveau système d'install de la 1.2.

Et dans les futurs scripts de desinstallation? :D