Re-Bonjour,

Désolé de squatter la liste en ce moment mais je reprends les développements sur mon site QScope.org et j'en viens à faire des choses un peu particulières.

Pour résumer mes motivations. J'héberge cette application chez OVH sur des VPS. Comme beaucoup d'offres chez OVH, l'entrée de gamme est très bon marché et plutôt performante, mais dès qu'on veut monter en puissance, le prix grimpe vite. Mon application est "prévue" pour pouvoir attribuer un serveur de base de données par utilisateur. Cela me permet de répartir les users sur différents "petits" serveurs qui restent performants et me coûtent moins cher. Actuellement j'en suis à 600 users (gratuits) pour 2M de lignes dans ma table principale (600Mo), certaines requêtes (des procédures stockées) viennent à générer 17000 "sous requêtes" sur en tout 1 milliard de lignes... Sur le "VPS Cloud 1" d'OVH ca tourne parfaitement bien, mais à terme je vise 2000 utilisateurs et 20 Millions de ligne (6Go). Pour pouvoir garantir une certaine qualité de service et un jour faire payer un peu quelques utilisateurs (et reverser mon obole aux briques logicielles que j'utilise), je veux donc pouvoir changer de serveur de BDD dynamiquement.

Tout fonctionne, sauf dans une liste déroulante d'un formulaire qui aujourd'hui utilise un DAO auquel je passe un paramètre dynamique (criteriafrom). J'ai essayé les autres méthodes : une classe ne me permet pas de passer un paramètre, et aller modifier la propriété data ($form->getControl('contest_name')->datasource->data = ) fonctionne mais ne peut pas récupérer le champ dynamiquement.

Je pensais donc essayer de modifier la propriété profile ($form->getControl('contest_name')->datasource->profile) ce qui aurait l'avantage de la simplicité et de la propreté, mais celle est ci est PROTECTED.

Deux questions :

• Y a-t-il un danger à la mettre en public ?
• Y a-t-il une autre méthode mieux adaptée ?

Merci d'avance pour vos idées. Cordialement, Yannick.

Bonjour,

Y a-t-il un danger à la mettre en public ?

Modifier le code de jelix n'est pas conseillé :-) (sauf à proposer le patch). Mais rendre cette propriété publique n'est pas très cohérent à mon avis

Y a-t-il une autre méthode mieux adaptée ?

Oui, j'ai trouvé mieux :-)

Dans un plugin de coordinateur, avant l’exécution d'une action, crée un profil virtuel qui soit un alias d'un profil existant. Par exemple, tu as 3 profiles A, B, C, et tu en choisi un des trois selon la méthode que tu veux (pas trop compris comment tu choisissais ce profil). En admettant que ce soit B, et que le nom du profile virtuel soit "dynamic" par exemple, tu feras

jProfile::createVirtualProfile ("jdb", "dynamic", "B");

Et partout où tu veux utiliser ce profil, en particulier dans ton formulaire, tu indiques "dynamic".

Bonjour Laurent,

Moi non plus je n'aime pas modifié le code de Jelix, et je me doute bien que si une variable est protected, c'est en principe pour une bonne raison... mais parfois la pression pour avoir quelque chose qui tourne est trop forte! En tous cas merci de me donner tes conseils sur le sujet.

Pour conclure. La modif finalement ne marchait qu'à moitié. En particulier ça ne marche pas avec les <datasource> qui accepte une propriété "criteria". Le code Javascript appelle une autre routine qui elle ne prend pas en compte la propriété "profile" modifiée... Et comme je ne sais pas faire d'AJAX moi-même, j'adore trop les "criteria" pour m'en passer.

La solution du profil virtuel me paraît parfaite. Reste plus qu'à la mettre en pratique. Deux choses que je n'avais pas saisi :

• on peut appeler un alias dans un profil virtuel (et j'utilise les alias bien entendu),
• le profil dans le DAO peut être virtuel (donc inexistant mais créé à la volée).

Pour choisir le profil, j'ai une colonne "db" en plus dans ma table jlx_user. Celle-ci contient l'identifiant de la base sur laquelle est l'utilisateur. J'ai une classe métier qui vient lire ça et définir le profil en fonction.

Encore merci, Yannick.

Bon, le résultat est mitigé. J'ai implémenté et ça fonctionne, mais pas tout le temps. Je continue à tester et à vérifier si ce n'est pas mon code qui est en cause, mais je ne vois pas trop.

Pour être plus clair, j'ai trois champs "<menulist>" dans mon formulaire :

• usr_login
• container (critère du DAO = usr_login)
• operator (critères = usr_login + container)

Dans le formulaire d'admin, usr_login est un "<menulist>". Dans le formulaire utilisateur, c'est un "<hidden>". Je change le nom du formulaire en fonction d'une règle jAcl2::check). Ce qui est bizarre, c'est que le champ container est toujours bien rempli dès le chargement de la page, donc il lit bien le usr_login. Par contre, pour remplir le champ "operator" j'ai besoin de rafraîchir (sélectionner un autre élément) dans la liste déroulante usr_login. Sinon il ne s'affiche pas. Pour l'admin, pas de problèmes, mais pour l'utilisateur qui n'a qu'un champ "hidden" c'est un peu plus dur... Voici mon formulaire :

<hidden ref="usr_login" />

<datasource dao="logs~view_contests_qso" profile="dynamic" method="findListeContests" criteriafrom="usr_login" labelproperty="contest_name, nb_qso" labelseparator=" : " valueproperty="contest_name"/>

<datasource dao="stats~view_operators_user_contest" profile="dynamic" method="findListeOperators" criteriafrom="usr_login,contest_name" labelproperty="operator" valueproperty="operator" />

Si je n'utilise pas les profils dynamiques, l'ancien code marche, et les modifications sont mineures entre le nouveau et l'ancien code...

Je continue à chercher. Yannick.