Question sur l'introspection

Bonjour, encore moi :oops:

J'ai besoin d'instancier une classe persistante dont je ne connais le type qu'à l'exécution... pas de soucis avec :

Code:

---

boost::any o = qx::create(...);

---

Maintenant, je souhaite définir les propriétés de "o", mais toujours en faisant abstraction du type de la classe persistante. Dans le tuto de QxBlog, il y a cet exemple :

Code:

---

1 2 3 4 5 6

// Création d'un 'blog' à partir du nom de la classe (design pattern 'factory') boost::any blog_any = qx::create("blog"); blog_ptr blog_1 = boost::any_cast<blog_ptr>(blog_any); blog_1->m_text = "blog_text_1"; blog_1->m_dt_creation = QDateTime::currentDateTime(); blog_1->m_author = author_1;

---

mais ça implique un "cast"...

Est il possible de faire un "setProperty("...", value)" sur un objet créé par qx::create sans en connaitre le type à la compilation ?

:salut:

Citation:

---

mais ça implique un "cast"...
Est il possible de faire un "setProperty("...", value)" sur un objet créé par qx::create sans en connaitre le type à la compilation ?

---

Oui c'est possible, voici 2 solutions à ton problème :

1- Est-ce que tu as une classe de base commune à toutes tes classes persistantes (QObject par exemple) ?
Si oui, pas de problème, tu peux "caster" avec la classe de base puis utiliser le moteur d’introspection pour valoriser les propriétés.
Voici un exemple avec une classe persistante ayant QObject comme classe de base, on valorise à 3 la propriété my_property de la classe MyQObject :

Code:

---

1 2 3 4 5

typedef boost::shared_ptr<QObject> QObject_ptr; boost::any any_object = qx::create("MyQObject"); QObject_ptr my_object = boost::any_cast<QObject_ptr>(any_object); qx::IxDataMember pData = qx::QxClassX::getDataMember("MyQObject", "my_property"); if (pData) { pData->setValue<int>(my_object.get(), 3); }

---

2- Si tu ne veux pas utiliser boost::any et boost::shared_ptr, il y a plus simple. Au lieu d'utiliser qx::create(...), tu peux utiliser qx::create_nude_ptr(...). Attention, ça crée un pointeur nu et ce sera à ton code de détruire l'instance (en faisant un delete).
Voici le même exemple que ci-dessus avec la classe MyObject qui ne dérive pas de QObject cette fois-ci (imaginons qu'elle n'a aucune classe de base, on passe alors par void *) :

Code:

---

1 2 3

void * pObject = qx::create_nude_ptr<void>("MyObject"); qx::IxDataMember pData = qx::QxClassX::getDataMember("MyObject", "my_property"); if (pData) { pData->setValue<int>(pObject, 3); }

---

Remarque : au lieu de setValue, tu peux aussi utiliser la méthode suivante :

Code:

---

pData->fromVariant(pObject, 3);

---

:yaisse2:

Super, exactement ce qu'il me fallait !

Juste une dernière question, est-ce l'on peut appeler qx::dao::save(pObject);

Code:

---

1 2 3 4 5

void * pObject = qx::create_nude_ptr<void>("MyObject"); qx::IxDataMember pData = qx::QxClassX::getDataMember("MyObject", "my_property"); if (pData) { pData->setValue<int>(pObject, 3); } qx::dao::save(pObject);

---

vu que pObject est un void*
:merci: pour ta disponibilité.

Désolé, je viens de tester et aucune des 2 solutions proposées dans mon message précédent ne fonctionne :aie: , mais l'idée était là :D
- la 1ère solution ne marche pas car boost::any ne supporte pas le polymorphisme (et donc encore moins le polymorphisme de pointeurs intelligents).
- la 2ème solution fonctionne uniquement si tu as une classe de base commune pour toutes tes classes persistantes. Si tu utilises void *, tu auras une erreur de compilation à cause d'un dynamic_cast. La correction à apporter n'est pas trop complexe, je le ferai dans la prochaine version de QxOrm...

Voici ce que tu peux faire facilement en attendant la prochaine version de QxOrm : dans le fichier './include/QxFactory/QxFactoryX.h', rend public la méthode 'static inline void * createInstanceNudePtr(const QString & sKey)' qui est actuellement private.
Du coup, le code de la 2ème solution devient :

Code:

---

1 2 3

void * pObject = qx::QxFactoryX::createInstanceNudePtr("MyObject"); qx::IxDataMember pData = qx::QxClassX::getDataMember("MyObject", "my_property"); if (pData) { pData->setValue<int>(pObject, 3); }

---

Citation:

---

Juste une dernière question, est-ce l'on peut appeler qx::dao::save(pObject);

---

Non, il faut connaitre le type de pObject pour appeler les fonctions qx::dao::....

Si tu veux implémenter un tel mécanisme, voici ce qui me semble le plus propre pour la conception :
- tu crées une interface (ou plutôt une classe abstraite en C++), du style IxPersistable, avec les méthodes virtuelles pures suivantes : fetch, update, insert, delete, save, etc...
- toutes tes classes persistantes doivent implémenter l'interface IxPersistable.
- ensuite tu utilises qx::create_nude_ptr<IxPersistable>(...) pour créer une instance d'un type persistant.
- à partir de là tu peux appeler la méthode save() par exemple.

Voilà ça fait beaucoup de boulot mais c'est ce qui me semble le plus propre.
Après faut voir avec ton besoin réel.
Dans quel contexte tu veux mettre un tel mécanisme en place ?

Je souhaite que mon prog puisse importer la BD TOPO de l'IGN en db.

Pour cela, je parse les fichiers shapefile (une trentaine au moins) et à chacun correspond une table (avec des champs différents).

La routine d'import étant toujours la même, je souhaitais développer une routine générique qui, en fonction du shapefile, créé une instance de la classe persistante correspondante, la renseigne avec les propriétés du shapefile, puis la sauve en db.

Les noms des champs de chaque table étant identiques aux champs des shapefiles correspondants, l'introspection me semblait être la solution.

Toutefois, dans ce cas précis, je peux créer les requêtes "INSERT INTO ..." manuellement, et donc maîtriser complètement le nom des tables et des champs, en m'appuyant sur qx::QxClassX, etc...

PS : j'ai utilisé la solution N°2 en utilisant QObject à la place de void. (sans modifier QxOrm)

Ça fonctionne, mais ne règle pas le problème qx::dao::save(...)

C'est d'ailleurs à ça que les "repository" pourraient servir '

Code:

---

repository<MonType>::save(MonObjet)

---

Citation:

---

PS : j'ai utilisé la solution N°2 en utilisant QObject à la place de void. (sans modifier QxOrm)

---

Oui si toutes tes classes persistantes dérivent de QObject, alors le code suivant fonctionne sans problème avec la version courante de QxOrm (c'est ce qui est utilisé par exemple avec le module QxService, en remplaçant QObject par qx::IxService) :

Code:

---

1 2 3

QObject * pObject = qx::create_nude_ptr<QObject>("MyQObject"); qx::IxDataMember pData = qx::QxClassX::getDataMember("MyQObject", "my_property"); pData->setValue<int>(pObject, 3);

---

Code:

---

1 2	C'est d'ailleurs à ça que les "repository" pourraient servir ' : repository<MonType>::save(MonObjet)

---

Je ne vois pas trop comment le code ci-dessus avec le repository pourrait résoudre ton problème : quand tu écris repository<MonType>, tu dois spécifier MonType, de la même façon que qx::dao::save<MonType>(...).
Je pense que l'intérêt d'un repository est d'avoir une interface commune pour effectuer les actions de persistance (fetch, insert, update, delete, etc.). Dans ton cas, il faudrait y accéder par le nom de la classe "MonType", au lieu du template <MonType>.

Donc je pense qu'un code comme ça pourrait résoudre ta problématique :

Code:

---

1 2	qx::IxRepository * pRepository = qx::QxRepositoryX::get("MonType"); pRepository->save(MonObjet);

---

T'en penses quoi ?

Ce n'est pas très complexe à mettre en place dans la bibliothèque QxOrm, je le ferai dans la prochaine version...
Par contre, j'ai un peu peur que ça rallonge fortement les temps de compilation des classes persistantes, donc je mettrai peut-être une option de compilation pour accéder au repository par introspection (si je vois pendant mes tests que ça dégrade trop la compil).
L'accès au repository par template sera toujours accessible (peu importe l'option de compilation s'il il y en a une), mais par nom de classe (l'exemple ci-dessus) on verra...
Sinon, l'interface qx::IxRepository aura des méthodes avec pour paramètres void * (certains diront BEURK mais je pense que c'est mieux que boost::any puisqu'il ne gère pas le polymorphisme, on fera des dynamic_cast pour vérifier l'instance passée en paramètre...).

Citation:

---

T'en penses quoi ?

---

Effectivement, tu as raison, ça ne résoudrais pas mon problème, par contre, ta proposition sur les repository permettrait de faire de l'introspection totale.

A voir en effet si les temps de compilations explosent...



Les interêts que je vois avec repository<T>

• Pouvoir en hériter et le surcharger avec ses propres méthodes CRUD en fonction des besoins, et ainsi centraliser les opérations CRUD.
• Simplifier l'instantiation des objets
  Code:

  ---

  qx::dao::ptr<MonType> monObjet = Repository<MonType>::getById(id);

  ---

Je vais te proposer de télécharger une pré-version de QxOrm 1.2.1 si tu veux.
Je te mettrai un lien de téléchargement ce soir...
Comme ça, on pourra valider ce pattern Repository qui est intéressant :)

La version que tu pourras télécharger contiendra :

• une nouvelle fonction void * qx::create_void_ptr(...) (cf. problématique du début de ce thread), comme ça même si tes objets persistants n'ont pas de classe de base, tu pourras passer par void * pour utiliser le moteur d'instrospection et valoriser tes propriétés ;
• implémentation du pattern Repository avec les 3 classes suivantes : qx::IxRepository, qx::QxRepository<T>, et qx::QxRepositoryX ;
• rien à voir avec ta problématique mais ce sera inclus dans cette version (comme ça tu pourras beta-tester si tu veux ;) ) : nouveau moteur pour générer des requêtes sans écrire de SQL à partir de la classe qx::QxSqlQuery (inspiré de l'excellent Subsonic pour .Net, par exemple : query.where("my_column").isEqualTo(3).and_("my_column2").isGreaterThan(4) ===> le gros intérêt est de ne plus avoir à binder ses paramètres et la syntaxe est très proche du SQL) ;
• rien à voir non plus avec ta problématique mais ça se rapproche quand même du repository : amélioration de la classe qx::QxSession ===> tu peux écrire ça par exemple : session.fetchById(3) (toutes les opérations de persistance peuvent être appelées plus facilement depuis une session) ;

Voilà, il n'y a aucune doc encore ni de test unitaire mais ça compile correctement (donc ça marche :D ).

Concernant la classe qx::QxRepositoryX, j'ai mis une option de compilation (_QX_AUTO_REGISTER_REPOSITORY) pour remplir la collection automatiquement. Je pense que par défaut, ce ne sera pas activé car ça répond quand même à une problématique bien particulière. Même sans l'option de compilation, tu peux remplir la collection en utilisant qx::register_repository<T>(sKey).

Tu pourras écrire quelque chose comme ça (même si on passe par void *, il y a une vérification du type à l'exécution) :

Code:

---

1 2	qx::IxRepository * pRepository = qx::QxRepositoryX::get("MonType"); pRepository->_save(MonObjet);

---

Toutes les remarques sont les bienvenues :D

J'ai crée un autre thread avec le lien vers une version BETA qui implémente le pattern repository :
http://www.developpez.net/forums/d11...a/#post6282427

Je ne sais pas si tu as eu le temps de tester la BETA 1.2.1 : en fait, je suis pas mal embêté avec ta problématique pour pouvoir écrire quelque chose comme ça et faire de l'introspection avec le repository :

Code:

---

1 2	qx::IxRepository * pRepository = qx::QxRepositoryX::get("MonType"); pRepository->_save(MonObjet);

---

Si l'interface qx::IxRepository propose des méthodes avec void * comme paramètres, je n'ai aucun moyen de vérifier le type à l’exécution du programme. Je pensais qu'un dynamic_cast pourrait faire l'affaire mais ça ne fonctionne pas avec void *. C'est donc potentiellement assez risqué puisqu'on peut passer n'importe quoi en paramètre et qu'on ne peut pas vérifier.

boost::any permet de faire cette vérification du type (sans gérer le polymorphisme). Mais ça signifie qu'il faut connaitre le type à un moment donné. Et donc ta problématique ne sera pas résolu (puisque tu veux travailler sans type).

Pour le moment, je préfère donc boost::any à void * car il y a une vérification au niveau du type et on évite ainsi de faire n'importe quoi, même si ça ne résout pas ta problématique.

Sans classe de base, je pense qu'il n'y a pas de solution, à moins qu'un GURU du C++ lit ce thread et trouve une solution...

EDIT: je pense avoir trouvé le meilleur compromis : puisqu'avec une classe de base ca fonctionnerait, on pourrait utiliser QObject. Ce serait la seule condition pour utiliser l interface qx::IxRepository. Pour les collections d objets, on pourrait passer par qx::IxCollection. Je fais une nouvelle beta en partant de ce principe et la proposerait en telechargement pour tests....

EDIT2: une nouvelle BETA est disponible (QxOrm_1.2.1_BETA_14) pour tests sur ce thread :
http://www.developpez.net/forums/d11...qxorm-1-2-1-a/
Je pense que le pattern repository est maintenant correctement implémenté et que ta problématique est résolue (introspection totale pour communiquer avec la BDD via la classe qx::IxRepository).

:salut:

J'étais en congé hier...

Je viens de tester l'introspection totale avec la dernière beta (1.2.1_14).

Vu que mes classes dérivent toutes de QObject, pas de problème :ccool:.

Mon code :

Code:

---

1 2 3 4 5 6

QString MonType("Le type à persister"); // je récupère cette valeur à l'exécution qx::IxRepository * pRepository = qx::QxRepositoryX::get(MonType); // Obtention du repository par introspection QObject * monObjet = qx::create_nude_ptr<QObject>(MonType); // Création d'une instance de classe persistance, toujours par introspection (Le repository peut'il s'en charger ? Voir suggestion ci après) monObjet->setProperty("monChamp", "Ma Valeur"); // l'introspection de Qt va très bien ici pour valoriser mes propriétés, vu que MonType dérive de QObject, mais on peux aussi passer par l'introspection de QxOrm si MonType ne dérive pas de QObject... pRepository->_save(monObjet); // persistance... delete monObjet;

---

Pour que ce code fonctionne, j'ai enregistré Repository<MonType> dans le contexte QxOrm de cette façon, (sans changer l'option de compilation) :

Code:

---

1 2 3 4 5 6 7

namespace qx{ template <> void register_class(QxClass<MonType> &t) { register_repository< MonType >("MonType"); // <<<<<< ici IxDataMember * pData = NULL; IxFunction * pFct = NULL; ............

---

Je pense que ça ne pose pas de problème d'enregistrer les Repository de cette façon (Mon programme appelle qx::QxClassX::registerAllClasses(); au lancement). Ainsi, je modifie chaque classe que je souhaite introspecter de cette façon. Tu me dis si je me trompe ?

Petite suggestion : Les repository, en plus de save, fetch, delete..., ne pourraient'ils pas implémenter create (CRUD) afin de remplacer

Code:

---

1 2 3

QObject * monObjet = qx::create_nude_ptr<QObject>(MonType); //par QObject * monObjet = pRepository->_create();

---

EDIT----
Cela m'ammène à penser : si les opérations CRUD étaient implémentées directement depuis IxClass, les Repository deviendraient inutiles...

Code:

---

1 2 3 4 5

qx::IxClass * pClass = qx::QxClassX::get("MonType"); QObject * pObject = pClass->create(); pObject->setProperty("monChamp", "Ma Valeur"); ......... pClass->save(pObject);

---

Citation:

---

Tu me dis si je me trompe ?

---

Non, ton code est parfait :ccool: : tu peux en effet appeler register_repository< MonType >("MonType"); depuis ta fonction de mapping, il faut juste être certain de charger toutes les classes (ce qui n'est pas fait par défaut pour optimisation et inutile dans la plupart des cas) en utilisant qx::QxClassX::registerAllClasses(); au lancement de l'application (ce que tu fais donc tout est OK).

Citation:

---

Les repository, en plus de save, fetch, delete..., ne pourraient'ils pas implémenter create (CRUD) afin de remplacer
......
si les opérations CRUD étaient implémentées directement depuis IxClass, les Repository deviendraient inutiles...

---

D'un point de vue conception, je ne pense pas que ce soit une bonne solution.
Je pense qu'il ne faut pas mélanger le rôle de chaque classe.
Le repository est utile pour proposer une interface commune pour les opérations de persistance. Créer une instance d'un pointeur par introspection n'est pas du tout son objectif.
Même chose pour qx::IxClass : son objectif est le moteur d'introspection, pas de proposer des méthodes de persistance.