En ajoutant 2 fonctions au plugin crayon je peux crayonner tablenonspip
sur baseexterne (à condition que celle ci soit déclarée explicitement)
tablenonspip_valeur_colonne_table_dist()
est une copie de valeur_colonne_table_dist() avec
spip_query("requete","basexterne")
etat_civil_revision()
est une copie de crayon_update() avec spip_query("requete","basexterne")
Seul hic, crayon.js ne rafraîchit pas la valeur crayonnée. Apparemment
jquery ne peut pas sélectionner la classe baseexterne:tablenonspip
ajouté pour le crayon a cause des ":"
Ça se passe ligne 254 de crayon.js.
Est-ce un bug jquery? Faut-il envisager d'enlever ces ":" du nom des
classes crayons?
En tout cas avce dans tetecrayons.php l185
$type = "$distant_$type"; à la place de $type = "$distant:$type";
le problème disparait.
Si ça ne crée pas d'autres problème peut-être faudrait-il le corriger?
Alexis a écrit :
Bonjour,
En ajoutant 2 fonctions au plugin crayon je peux crayonner tablenonspip
sur baseexterne (à condition que celle ci soit déclarée explicitement)
tablenonspip_valeur_colonne_table_dist()
est une copie de valeur_colonne_table_dist() avec
spip_query("requete","basexterne")
etat_civil_revision()
est une copie de crayon_update() avec spip_query("requete","basexterne")
Seul hic, crayon.js ne rafraîchit pas la valeur crayonnée. Apparemment
jquery ne peut pas sélectionner la classe baseexterne:tablenonspip
ajouté pour le crayon a cause des ":"
Ça se passe ligne 254 de crayon.js.
Est-ce un bug jquery? Faut-il envisager d'enlever ces ":" du nom des
classes crayons?
En tout cas avce dans tetecrayons.php l185
$type = "$distant_$type"; à la place de $type = "$distant:$type";
le problème disparait.
Si ça ne crée pas d'autres problème peut-être faudrait-il le corriger?
Non car le underscore est un caractère très courant dans les noms de
champs. Il faut peut-être trouver un autre séparateur
-- Fil
De retour de vacances je me suis replongé dans le code de crayon.
JQuery n'accepte pas grand chose comme caractère dans le nom des
classes, serait-il possible d'utiliser 2 underscores __ ?
J'ai essayé quelques modifs pour le support du crayon sur base distante
sans fonction déclaration explicite ni fonction supplémentaire. Il n'a
pas beaucoup de code mais dans 4 fichiers.
J'aimerais les soumettre quelque part mais je ne sais pas trop comment
m'y prendre.
En tout cas avce dans tetecrayons.php l185
$type = "$distant_$type"; à la place de $type = "$distant:$type";
le problème disparait.
Si ça ne crée pas d'autres problème peut-être faudrait-il le corriger?
Non car le underscore est un caractère très courant dans les noms de
champs. Il faut peut-être trouver un autre séparateur
-- Fil
De retour de vacances je me suis replongé dans le code de crayon.
JQuery n'accepte pas grand chose comme caractère dans le nom des
classes, serait-il possible d'utiliser 2 underscores __ ?
J'ai essayé quelques modifs pour le support du crayon sur base distante
sans fonction déclaration explicite ni fonction supplémentaire.
L'utilisation des crayons sur une base externe est une fausse bonne idée.
A commencer parce que l'API SQL actuelle n'est capable de gérer les bases externes qu'en *lecture*.
Les fonctions d'écritures (insert, update) ne sont pas prévues à ce jour pour gérer les bases externes.
Il va donc y avoir des problèmes de support et de compatibilité et des bugs insolubles.
En tout cas avce dans tetecrayons.php l185
$type = "$distant_$type"; à la place de $type = "$distant:$type";
le problème disparait.
Si ça ne crée pas d'autres problème peut-être faudrait-il le corriger?
Non car le underscore est un caractère très courant dans les noms de
champs. Il faut peut-être trouver un autre séparateur
-- Fil
De retour de vacances je me suis replongé dans le code de crayon.
JQuery n'accepte pas grand chose comme caractère dans le nom des
classes, serait-il possible d'utiliser 2 underscores __ ?
J'ai essayé quelques modifs pour le support du crayon sur base distante
sans fonction déclaration explicite ni fonction supplémentaire.
L'utilisation des crayons sur une base externe est une fausse bonne idée.
A commencer parce que l'API SQL actuelle n'est capable de gérer les
bases externes qu'en *lecture*.
Les fonctions d'écritures (insert, update) ne sont pas prévues à ce jour
pour gérer les bases externes.
Il va donc y avoir des problèmes de support et de compatibilité et des
bugs insolubles.
Cédric
Il n'y a qu'une instruction d'écriture à adapter dans crayon,
spip_query($q=UPDATE...
En passant simplement le nom de la connexion distante l'écriture se fait
sans soucis apparent avec MYSQL.
Il n'y avait pas grand chose d'autre à ajouter dans le plugin, juste à
vérifier systématiquement si on est sur une base distante.
Ce serait peut-être dommage de se priver de cette fonctionnalité quitte
à la désactiver selon le type de db si pour sqllite ou autre l'écriture
sur base distante posait problème.
En tout cas avce dans tetecrayons.php l185
$type = "$distant_$type"; à la place de $type = "$distant:$type";
le problème disparait.
Si ça ne crée pas d'autres problème peut-être faudrait-il le corriger?
Non car le underscore est un caractère très courant dans les noms de
champs. Il faut peut-être trouver un autre séparateur
-- Fil
De retour de vacances je me suis replongé dans le code de crayon.
JQuery n'accepte pas grand chose comme caractère dans le nom des
classes, serait-il possible d'utiliser 2 underscores __ ?
J'ai essayé quelques modifs pour le support du crayon sur base distante
sans fonction déclaration explicite ni fonction supplémentaire.
L'utilisation des crayons sur une base externe est une fausse bonne idée.
A commencer parce que l'API SQL actuelle n'est capable de gérer les
bases externes qu'en *lecture*.
Les fonctions d'écritures (insert, update) ne sont pas prévues à ce jour
pour gérer les bases externes.
Il va donc y avoir des problèmes de support et de compatibilité et des
bugs insolubles.
Cédric
Il n'y a qu'une instruction d'écriture à adapter dans crayon,
spip_query($q=UPDATE...
En passant simplement le nom de la connexion distante l'écriture se fait
sans soucis apparent avec MYSQL.
Non.
spip_query ne permet pas la portabilité PostGreSQL, mysqlite etc ...
Non.
spip_query ne permet pas la portabilité PostGreSQL, mysqlite etc ...
Cédric
C'est bien ce que j'avais compris dans le message précédent c'est pour
cela que je proposais de la
désactiver pour les db ne supportant pas (encore?) l'écriture sur base
distante.
Je ne pensais pas être tout seul à m'intéresser au crayonnage de base
distante :
L'article (Archive) MultiBase sur SPIP 1.9.3 parle de brancher des
crayons sur des tables de db externe (si la db est déclarer explicitement)
L'article Les crayons - SPIP-Contrib explique que n'importe
quelle table avec une clef primaire id_nom_table est crayonnable.
Et dans le code même du plugin :
//crayon sur une base distante 'nua:article-intro-5'
// on ne sait pas encore les gerer, mais au moins on les detecte
En tout cas j'ai un bout de code qui essaye de répondre à ça et que j'ai
tester dans le cas d'une base mysql.
C'est bien ce que j'avais compris dans le message précédent c'est pour
cela que je proposais de la
désactiver pour les db ne supportant pas (encore?) l'écriture sur base
distante.
C'est pas un problème de "supporter ou pas", car parfois tout
simplement tu n'as pas le droit de modifier ta base distante. Mais
c'est bien aux fonctions autoriser() de gérer ces cas. Et
éventuellement, si on a oublié de programmer le autoriser(), mais que
le UPDATE n'a pas fonctionné, aux crayons de donner un code de retour
d'erreur pour dire "je n'ai pas réussi à modifier le contenu".
Je ne pensais pas être tout seul à m'intéresser au crayonnage de base
distante :
Non tu n'es pas tout seul
En tout cas j'ai un bout de code qui essaye de répondre à ça et que j'ai
tester dans le cas d'une base mysql.
C'est bien ce que j'avais compris dans le message précédent c'est pour
cela que je proposais de la
désactiver pour les db ne supportant pas (encore?) l'écriture sur base
distante.
C'est pas un problème de "supporter ou pas", car parfois tout
simplement tu n'as pas le droit de modifier ta base distante. Mais
c'est bien aux fonctions autoriser() de gérer ces cas. Et
éventuellement, si on a oublié de programmer le autoriser(), mais que
le UPDATE n'a pas fonctionné, aux crayons de donner un code de retour
d'erreur pour dire "je n'ai pas réussi à modifier le contenu".
Il faut que je reprenne ce morceau alors.
En tout cas j'ai un bout de code qui essaye de répondre à ça et que j'ai
tester dans le cas d'une base mysql.
Cool. As-tu résolu la question du séparateur ?
-- Fil
JQuery ne donne pas beaucoup de choix. Le moindre caractère un peu
spécial dans une classe et celle-ci n'est plus sélectionnable. *,&,%,+:
rien ne passe. En définitive j'ai utilisé deux underscore accolé "__".
On risque d'avoir ça dans un nom de table?
Je t'enverrais le résultat quand j'aurais ajouter le retour d'erreur "je
n'ai pas réussi à modifier le contenu".
JQuery ne donne pas beaucoup de choix. Le moindre caractère un peu
spécial dans une classe et celle-ci n'est plus sélectionnable. *,&,%,+:
rien ne passe. En définitive j'ai utilisé deux underscore accolé "__".
On risque d'avoir ça dans un nom de table?
peut-être, mais en effet plus rare ; cependant c'est pas super lisible
il y a d'autres caractères qui pourraient être safe : à tester par
exemple = $ | ! ? @
JQuery ne donne pas beaucoup de choix. Le moindre caractère un peu
spécial dans une classe et celle-ci n'est plus sélectionnable. *,&,%,+:
rien ne passe. En définitive j'ai utilisé deux underscore accolé "__".
On risque d'avoir ça dans un nom de table?
peut-être, mais en effet plus rare ; cependant c'est pas super lisible
il y a d'autres caractères qui pourraient être safe : à tester par
exemple = $ | ! ? @
-- Fil
Non rien de tout ça.
Cela dit j'étais passer un peu vite sur "*" qui marche. Il y a aussi
"€","£".
Non rien de tout ça.
Cela dit j'étais passer un peu vite sur "*" qui marche. Il y a aussi
"€","£".
* c'est pas mal, si effectivement ça marche. Mais € ou £ ça ne va pas
car ce n'est pas de l'ascii 7 bits, d'où des risques de changements
intempestifs de charsets.
