Salut la liste,
j’ai rencontré des problèmes avec crayons dans 2 situations :
c’était tout betement des champs que j’avais ajouté à spip_articles, de type VARCHAR(20)
Symptome :
Crayon apparait, mais la modification n’est pas prise en compte
Vous y comprenez quelque chose ?
.Gilles
j'ai rencontré des problèmes avec crayons dans 2 situations :
- Un champ au pluriel : #KILOMETRES (corrigé si remplacé par #KILOMETRE)
chez moi ça marche très bien les #KILOMETRES
- Un champ composé : #TYPE_VEHICULE (corrigé si remplacé par #TYPEVEHICULE)
la chaîne "type_" est réservée, suite au commit
Ce serait bien de corriger ça
-- Fil
Le Tuesday 19 May 2009 22:40:08 Fil, vous avez écrit :
> j'ai rencontré des problèmes avec crayons dans 2 situations :
> - Un champ au pluriel : #KILOMETRES (corrigé si remplacé par #KILOMETRE)chez moi ça marche très bien les #KILOMETRES
> - Un champ composé : #TYPE_VEHICULE (corrigé si remplacé par
> #TYPEVEHICULE)la chaîne "type_" est réservée, suite au commit
Connexion · GitLab
Ce serait bien de corriger ça-- Fil
De préférence sans "foutre en l'air" la notion de type de crayon. Attention le
mot "type" apparait à plusieurs reprises dans les sources, pour des notions
différentes.
Le typage des crayons permet des usages étendus des crayons, comme
les "pinceaux" ACS : http://acs.geomaticien.org/spip.php?article65
(personnalisation de la partie publique en Ajax)
A ce jour, il existe (à ma connaissance) au moins trois "familles" d'usages
des crayons :
- les crayons d'édition d'un champ (usage classique, le plus courant)
- les crayons d'édition d'un fichier
- les pinceaux
Les deux premiers types ne sont pas bien différenciés dans le code, mais ça
pourrait être pratique pour simplifier l'appel des bons CVT
L'idéal serait de typer les crayons partout dans le code du plugin pour
permettre facilement d'utiliser une icône et un jeu de CVT spécifique par
type de crayon, si possible en préservant la compatibilité, bien entendu ...
L'idée serait qu'à chaque type est associé un jeu CVT spécifique :
il y aurait ainsi (au moins) trois types plus la possibilité d'en créer de
nouveaux :
- le type "champ"
- le "type" fichier"
- le type "pinceau"
- ... ?
Qu'en pensez-vous ?
Si analyse OK, je pourrais proposer un "correctif", qui serait plutôt une
extension.
-----
Info compémentaire sur les pinceaux et les crayons dans le plugin ACS :
Le plugin ACS fournit une interface qui permet de configurer par "clickodrome
ajaxifié" le fonctionnement, les couleurs et les styles des composants des
squelettes du site public. Ces composants sont des ensembles regroupant zéro,
une ou plusieurs "noisettes" (bouts de squelettes) et une description xml des
variables qu'ils permettent de paramétrer, ce qui leur fournit une interface
d'administration utilisable dans l'espace privé, ET dans l'espace public avec
les "pinceaux" (qui sont des crayons de type "pinceau" utilisés pour appeller
l'interface d'admin d'un composant depuis le site public, en Ajax).
Les composants sont multilingues, et ACS utilise également le plugin "crayons"
pour l'édition directe des fichiers de traductions de chaque composant par
l'interface web.
ACS utilise également les crayons pour l'édition directe de toutes les
variables du modèle ACS actif sur l'onglet "variables" de l'interface d'admin
(son affichage est optionnel: case à cocher onglet Admin).
Enfin, la dernière version (pas encore commitée) permet d'éditer directement
le code source des squelettes de pages, modèles, formulaires, et pages de
composants ACS, faisant ainsi d'ACS un éditeur de squelettes SPIP
multilingues.
Dans la partie privée du site, ACS présente déjà l'ensemble des pages de
squelettes utilisées par un site (issues de la dist, d'ACS ou d'autres
plugins), ce qui en fait déjà un "explorateur spip" montrant ensemble toutes
les pages et morceaux de squelettes utilisés par SPIP quel que soient les
dossiers dans lesquelles celles-ci sont rangées, en les présentant toutes
ensemble classées non par dossier source mais par types de pages : pages de
squelettes, inclusions, modèles, formulaires, pages de composants, etc.
Chaque page et chaque "noisette" peut être affichée sous forme de schéma
simplifié, de schéma détaillé, ou de code source colorisé (éditable par
crayons étendus dans la dernière version à commiter).
Cdt,
--
Daniel FAIVRE
PS : pour développeurs de squelettes configurables qui essaient ACS, voici un
truc très pratique : ACS contient par défaut un jeu de squelettes entièrement
configurable par "clicks", le modèle "Cat", qui sert de catalogue d'exemples.
Pour utiliser un modèle ACS (Cat, Dist, ..) ET un autre jeu de squelettes
ensemble, il faut "surcharger" ACS (override), ce qui se fait simplement en
indiquant le ou les dossiers de squelettes à utiliser en override dans
l'interface d'admin d'ACS, onglet "Administration". Les squelettes en
surcharge au dessus du modèle ACS actif peuvent aussi bien utiliser les
composants "de base" que définir des composants personnalisés spécifiques
ou "overrider" les composants du modèle ACS actif.
De préférence sans "foutre en l'air" la notion de type de crayon.
On peut aussi considérer que l'ajout des "types" a foutu en l'air la
notion de crayon... 
En tous cas le fait que #EDIT{type_vehicule} ne marche plus est un bug
introduit par cette histoire de type ; est-ce que le "type" (le tien)
ne devrait pas être noté par un caractère autre que le _, lequel sert
souvent à nommer une table ?
-- Fil
Le 20 mai 2009 09:29, Fil <fil@rezo.net> a écrit :
De préférence sans « foutre en l’air » la notion de type de crayon.
On peut aussi considérer que l’ajout des « types » a foutu en l’air la
notion de crayon…En tous cas le fait que #EDIT{type_vehicule} ne marche plus est un bug
introduit par cette histoire de type ; est-ce que le « type » (le tien)
ne devrait pas être noté par un caractère autre que le _, lequel sert
souvent à nommer une table ?
est-ce qu’il est possible d’utiliser un caractere non alpahnumerique ? genre §type, @type … ce qui peut eviter d’avoir un mot reserves ?
Arnaud
Le Wednesday 20 May 2009 09:29:36 Fil, vous avez écrit :
> De préférence sans "foutre en l'air" la notion de type de crayon.
On peut aussi considérer que l'ajout des "types" a foutu en l'air la
notion de crayon...
Certes ... mais bon, vu que celà touchait aux crayons, je n'avais pas fait
cette modif sans t'en parler et bien expliquer le pourquoi.
En dehors du cas particulier du plugin ACS, gros consommateur de "crayons" et
surtout de crayons étendus, d'autres plugins peuvent en tirer bénéfice, dans
la mesure où celà permet des "crayons" plus sophistiqués (un controleur
draggable, par exemple).
Le "type" des crayons classiques ne correspond pas à un type, mais en fait à
une table. Le type des crayons typés est passé par la classe type_<type>,
Le simple fait de remplacer ce "type" là par "table" pour les crayons
classiques rendrait déjà le code plus aisé à comprendre pour qui le découvre.
En tous cas le fait que #EDIT{type_vehicule} ne marche plus est un bug
introduit par cette histoire de type ;
Est-ce bien certain ? Le "type" que j'ai introduit est passé par la classe
type_<type> : pourquoi celà empecherait-il de modifier type_vehicule si le
crayon est un truc du genre vehicules-type_vehicule-id ? Comment une autre
classe, type_<type>, interfère t'elle ???
Si c'est bien le fait de définir une classe type_<type> dans la classe du
crayon qui pose problème, alors le bug est dans la détection du type de
crayon et non dans la définition de son type.
est-ce que le "type" (le tien)
ne devrait pas être noté par un caractère autre que le _, lequel sert
souvent à nommer une table ?-- Fil
Si, c'est une possibilité.
Avantage : vite fait.
Inconvénients :
1) Fout en l'air la compatibilité ascendante.
2) ne résoud pas le problème de fond : certaines fonctions des crayons sont
tellement "orientées table et champ" que leur usage étendu est délicat, et
conduit à du code pas aussi propre que l'on voudrait. Par exemple,
crayon_html.php contient une fonction valeur_colonne_table() pour vérifier la
valeur d'un champ avant MàJ, ce qui est bien évidement inadapté pour des
crayons étendus destinés àç modifier un fichier ou autre chose (comme un
composant ACS, càd une ou plusieurs "noisettes").
Une autre solution possible serait de rajouter un quatrieme parametre aux
crayons, son type (ainsi un crayon classique de type "champ" serait défini
par exemple par champ-article-chapo-1247 et non plus seulement par
article-chapo-1247)
Inconvénients : nécessite de préserver au moins provisoirement les crayons à
trois paramètres pour conserver la compatibilité ascendante. De plus, la
modification est nettement plus importante : il faudrait restructurer le
plugin crayons pour bien y intégrer la notion de type de crayon, celui-ci
jouant sur :
- le jeu de CVT à utiliser
- l'icone du crayon (qui est définie par la classe type_<type>, justement)
- les fonctions de tests lors des MàJ.
Avantages :
- permet de faire du code plus propre pour n'importe quel crayon et de
simplifier les tests d'appel du bon controleur.
- rendrait le code des crayons plus facile à étendre pour d'autres crayons
étendus comme les pinceaux ACS.
Est-ce qu'il vous semblerait envisageable (et pertinent) de typer les crayons
ainsi ?
Et plus généralement, plutot que de faire un patch vite fait, ne devrait-on
pas réfléchir à la façon la plus propre de définir des "crayons étendus"
propres et faciles à coder pour crayonner des champs, des fichiers,
des "noisettes", des composants (comme ACS) et tout ce que les développeurs
inventeront et qu'on a pas encore prévu ?
Cdt,
Daniel FAIVRE
Le 20 mai 2009 16:00, Daniel FAIVRE <webmaster@geomaticien.com> a écrit :
Le Wednesday 20 May 2009 09:29:36 Fil, vous avez écrit :
De préférence sans « foutre en l’air » la notion de type de crayon.
On peut aussi considérer que l’ajout des « types » a foutu en l’air la
notion de crayon…Certes … mais bon, vu que celà touchait aux crayons, je n’avais pas fait
cette modif sans t’en parler et bien expliquer le pourquoi.
En dehors du cas particulier du plugin ACS, gros consommateur de « crayons » et
surtout de crayons étendus, d’autres plugins peuvent en tirer bénéfice, dans
la mesure où celà permet des « crayons » plus sophistiqués (un controleur
draggable, par exemple).
Le mieux est l’ennemi du bien. Ca m’est personellement égal que les crayons aient plein de features avancées, si la feature de base ne marche plus correctement.
…
En tous cas le fait que #EDIT{type_vehicule} ne marche plus est un bug
introduit par cette histoire de type ;Est-ce bien certain ? Le « type » que j’ai introduit est passé par la classe
type_ : pourquoi celà empecherait-il de modifier type_vehicule si le
crayon est un truc du genre vehicules-type_vehicule-id ? Comment une autre
classe, type_, interfère t’elle ???
Dans
http://zone.spip.org/trac/spip-zone/changeset/21861#L374
Il me semble que
var ctype = this.className.match(/\btype_(\w+)\b/);
va matcher
XXX-type_vehicule-12
le bug s’en suivant…
Au passage, il faudrait éviter de commit une réindentation complète d’un code avec des modifs. Le diff est proprement illisible et inutilisable, ce qui décourage toute personne censée de chercher le bug.
…
Avantage : vite fait.
Inconvénients :
- Fout en l’air la compatibilité ascendante.
L’utilisation de #EDIT est censée permettre une modif du formalisme interne sans aucune rupture de compat.
Le problème est que ton extension fonctionnelle ne passe pas par #EDIT, et du coup ça va effectivement te casser la compat de tes crayons étendus
- ne résoud pas le problème de fond : certaines fonctions des crayons sont
tellement « orientées table et champ »
Note bien que c’était l’objectif initial du plugin, non ?
que leur usage étendu est délicat, et
conduit à du code pas aussi propre que l’on voudrait.
…
En résumé, il faudrait veiller à ce qu’une feature étendue du plugin qui concerne 5% des utilisateurs ne vienne pas générer 90% de lourdeur dans le code, et les bugs qui vont avec.
Dans le logiciel libre, les usines à gaz ont souvent vocation à mourir à terme, car le jour ou la seule personne qui s’y retrouve n’est plus là, personne ne reprend le flambeau.
Autrement dit, il vaut mieux faire des petits modules autonomes et indépendants dans leurs codes qu’un gros truc qui essaye de tout faire.
Cédric
Est-ce bien certain ?
je ne fais confiance qu'au code :
svn up -r 21882 plugins/_stable_/crayons/
=> pas de bug sur #EDIT{type_vehicule}
svn up -r 21883 plugins/_stable_/crayons/
=> bug sur #EDIT{type_vehicule}
Il me semble qu'il y a un /^type_/ dans le code qui provoque ce bug
sur un champ nommé type_vehicule.
1) Fout en l'air la compatibilité ascendante.
est-ce un problème en l'espèce ? je crois que tu en es le seul utilisateur
Une autre solution possible serait de rajouter un quatrieme parametre aux
crayons, son type (ainsi un crayon classique de type "champ" serait défini
par exemple par champ-article-chapo-1247 et non plus seulement par
article-chapo-1247)
"champ-" pourrait être la valeur par défaut en effet, ce qui ne
changerait rien à l'existant
De plus, la
modification est nettement plus importante : il faudrait restructurer le
plugin crayons pour bien y intégrer la notion de type de crayon, celui-ci
jouant sur :
- le jeu de CVT à utiliser
- l'icone du crayon (qui est définie par la classe type_<type>, justement)
- les fonctions de tests lors des MàJ.
Oui c'est pour ça que choisir @ au lieu de _ semble une piste plus directe...
Et plus généralement, plutot que de faire un patch vite fait, ne devrait-on
pas réfléchir à la façon la plus propre de définir des "crayons étendus"
propres et faciles à coder pour crayonner des champs, des fichiers,
des "noisettes", des composants (comme ACS) et tout ce que les développeurs
inventeront et qu'on a pas encore prévu ?
Le fait d'ajouter un "type" ne suffit-il pas à gérer tous ces cas ?
-- Fil
Le Wednesday 20 May 2009 16:40:25 Fil, vous avez écrit :
> Est-ce bien certain ?
je ne fais confiance qu'au code :
svn up -r 21882 plugins/_stable_/crayons/
=> pas de bug sur #EDIT{type_vehicule}svn up -r 21883 plugins/_stable_/crayons/
=> bug sur #EDIT{type_vehicule}Il me semble qu'il y a un /^type_/ dans le code qui provoque ce bug
sur un champ nommé type_vehicule.> 1) Fout en l'air la compatibilité ascendante.
est-ce un problème en l'espèce ? je crois que tu en es le seul utilisateur
Oui et non : pour ACS, aucun pb majeur à changer ça, même si ça va obliger à
tout faire en double tant que je dois gérer plusieurs versions des crayons
pour rester compatible avec de plus vieilles versions de spip. (crayons est
censé marcher à partir de la 1.9.2, je crois, et ACS aussi)
Mais je pense que ce besoin va se développer, et que bien d'autres vont
ajaxifier plein de choses à coups de crayons, pour le plus grand bénéfice de
tout le monde ! Bref, si j'insiste, c pas tant pour me "simplifier" la vie
sur le dev d'ACS que pour essayer de prévenir le meme genre de soucis pour
ceux qui voudront étendre les crayons . Je pense pour avoir justement été
l'un des premiers sinon un des seuls à étendre les crayons pour ce genre
d'usages que le code des crayons pourrait évoluer pour etre plus générique,
c'est à dire non typé champ.
> Une autre solution possible serait de rajouter un quatrieme parametre aux
> crayons, son type (ainsi un crayon classique de type "champ" serait
> défini par exemple par champ-article-chapo-1247 et non plus seulement par
> article-chapo-1247)"champ-" pourrait être la valeur par défaut en effet, ce qui ne
changerait rien à l'existant
c'est une solution qui me plait beaucoup, parce qu'il me semble que celà
permettrait progressivement de rendre les crayons de plus en plus génériques,
en particulier en ne traitant comme champs que les crayons concernant
effectivement des champs, et en généralisant les noms de certaines
fonctions "orientées table".
> De plus, la
> modification est nettement plus importante : il faudrait restructurer le
> plugin crayons pour bien y intégrer la notion de type de crayon, celui-ci
> jouant sur :
> - le jeu de CVT à utiliser
> - l'icone du crayon (qui est définie par la classe type_<type>,
> justement) - les fonctions de tests lors des MàJ.Oui c'est pour ça que choisir @ au lieu de _ semble une piste plus
directe...
Oui, mais l'absence de typage des crayons rend le code pour appeller tel ou
tel CVT moins propre, à mon avis.
> Et plus généralement, plutot que de faire un patch vite fait, ne
> devrait-on pas réfléchir à la façon la plus propre de définir des
> "crayons étendus" propres et faciles à coder pour crayonner des champs,
> des fichiers, des "noisettes", des composants (comme ACS) et tout ce que
> les développeurs inventeront et qu'on a pas encore prévu ?Le fait d'ajouter un "type" ne suffit-il pas à gérer tous ces cas ?
-- Fil
oui. la question est
- passer le type comme maintenant et debugger l'effet de bord sur type_truc en
mettant autre chose qu'un underscore. (workaround qui laisse le code "typé
champ" et pas généralisé)
- ou faire evoluer les crayons vers des crayons typés, dont le type par defaut
serait le type champ. (extension).
Si tu veux, je suis ok pour bosser la dessus, soit à patcher un workaround
vite fait, soit à rendre les crayons plus generiques sans rien casser (
dans les jours qui viennent.
--
Daniel
- passer le type comme maintenant et debugger l'effet de bord sur type_truc en
mettant autre chose qu'un underscore. (workaround qui laisse le code "typé
champ" et pas généralisé)
ça je vois à peu près ce que ça signifie
- ou faire evoluer les crayons vers des crayons typés, dont le type par defaut
serait le type champ. (extension).
ça non
Si tu veux, je suis ok pour bosser la dessus, soit à patcher un workaround
vite fait, soit à rendre les crayons plus generiques sans rien casser (
dans les jours qui viennent.
Je ne sais pas comment me "prononcer" vu que je ne comprends pas
l'alternative proposée.
-- Fil
Le Thursday 21 May 2009 10:35:36 Fil, vous avez écrit :
> - passer le type comme maintenant et debugger l'effet de bord sur
> type_truc en mettant autre chose qu'un underscore. (workaround qui
> laisse le code "typé champ" et pas généralisé)ça je vois à peu près ce que ça signifie
> - ou faire evoluer les crayons vers des crayons typés, dont le type par
> defaut serait le type champ. (extension).ça non
ça voudrait dire ajouter à la classe qui définit un crayon son type, comme
ceci :
champ-article-titre-id au lieu de article-titre-id
Pour compatibilité, les crayons "à trois variables" seraient par défaut des
crayons de type "champ".
Le type d'un crayon ne doit pas etre confondu avec l'objet crayonné, pour
permettre d'avoir eventuellement plusieurs types de crayons pour un meme
objet. Exemple : modif classique d'un champ, ou controleur specifique
étendant les possibilités d'edition de ce champ.
Si le type de crayon est défini par l'objet édité, alors il ne pourrait
exister qu'un type de crayon par objet.
> Si tu veux, je suis ok pour bosser la dessus, soit à patcher un
> workaround vite fait, soit à rendre les crayons plus generiques sans rien
> casser (Je ne sais pas comment me "prononcer" vu que je ne comprends pas
l'alternative proposée.-- Fil
--
Daniel
Daniel FAIVRE a écrit :
ça voudrait dire ajouter à la classe qui définit un crayon son type, comme ceci :
champ-article-titre-id au lieu de article-titre-idPour compatibilité, les crayons "à trois variables" seraient par défaut des crayons de type "champ".
et un autre exemple "pas comme avant" ?
JL
POur info :
JLuc a écrit :
et un autre exemple "pas comme avant" ?
> Daniel FAIVRE a écrit :
les autres types qui me semblent génériques sont (par exemple) un type "fichier" (des crayons pour éditer des fichiers), un type "pinceau" (pour éditer le design, comme dans ACS), mais il y a beaucoup de possibilités.
Le problème des crayons actuels est leur orientation "champ" (usage originel), alors que l'on peut désirer un "pinceau" pour éditer le design d'un champ plutot que son contenu, ou un crayon étendu pour éditer plusieurs champs en même temps (un formulaire, par exemple), ou encore simplement pouvoir utiliser deux types de crayons différents sur un meme champ, selon le contexte.
La confusion entre type de crayon et table empeche durablement d'écrire proprement de telles extensions.
En ce qui concerne ACS, ACS utilise les crayons pour ses "pinceaux", afin d'afficher des controleurs "draggables" permettant une mise à jour en ajax d'éléments de design ou de paramètres de fonctionnement d'une ou plusieurs "noisette" SPIP.
ACS utilise également intensivement les crayons dans la partie privée, par exemple pour éditer des fichiers de traductions.Pour les pinceaux ACS : cf mini-vidéo : http://acs.geomaticien.org/spip.php?article65