Bonjour,
Est-il assez générique de fournir une classe relativement identifiante à chaque li si le champs css n'a pas été renseigné.
En d'autres terme #ENV{css} deviendrait #ENV{css,lien-#ENV{rang}}
Si oui je comite....
Merci pour ce super plugin.
pierre
Le 27/04/2010 20:05, Pierre Fiches a écrit :
Bonjour,
Est-il assez générique
Là comme ça, je vois pas trop pour l'instant : tu peux expliquer pour quelles utilisations ça servirait ? Comme ça on verra si c'est un truc fréquent ou pas.
--
RastaPopoulos
Le 27 avr. 10 à 20:56, RastaPopoulos a écrit :
Le 27/04/2010 20:05, Pierre Fiches a écrit :
Bonjour,
Est-il assez générique
Là comme ça, je vois pas trop pour l'instant : tu peux expliquer pour quelles utilisations ça servirait ? Comme ça on verra si c'est un truc fréquent ou pas.
les deux usages que j'ai eu sont donner facilement une couleur ou une largeur à un élément
pierre
Le 27/04/2010 21:21, Pierre Fiches a écrit :
les deux usages que j'ai eu sont donner facilement une couleur ou une
largeur à un élément
Alors les numéros, je vois pas trop comment ils pourraient être génériques puisque ça veut rien dire, tu peux changer l'ordre.
Donc si tu veux donner un style à un élément précis, tu lui donnes une classe que tu connais, non ?
En revanche je vois des choses qui vont dans le même sens et qui sont génériques car indépendants de l'élément :
- connaitre le premier et le dernier élément (leur ajouter une classe "first" et "last" par exemple)
- pouvoir styler les entrées paires et impaires, comme pour les tableaux
--
RastaPopoulos
Le 27 avr. 10 à 23:00, RastaPopoulos a écrit :
Le 27/04/2010 21:21, Pierre Fiches a écrit :
les deux usages que j'ai eu sont donner facilement une couleur ou une
largeur à un élémentAlors les numéros, je vois pas trop comment ils pourraient être génériques puisque ça veut rien dire, tu peux changer l'ordre.
Donc si tu veux donner un style à un élément précis, tu lui donnes une classe que tu connais, non ?
oui et non l'automatisme sur la construction de la classe permet de gagner du temps et de s'adapter après coup sans retouche à ce niveau. Le changement d'ordre est comparativement moins génant même si ça suppose une intervention manuelle parce qu'il n'est pas gérable automatiquement une fois sur deux environ (cas des border left ou right pas forcément appliqué à toute le collection, harmonie des couleurs..... Ceci dit c'est sur qu'un identifiant fixe serait encore mieux (initiale de l'objet_id_objet)
En revanche je vois des choses qui vont dans le même sens et qui sont génériques car indépendants de l'élément :
- connaitre le premier et le dernier élément (leur ajouter une classe "first" et "last" par exemple)
oui c'est parfois utile
- pouvoir styler les entrées paires et impaires, comme pour les tableaux
pourquoi pas ?
pierre
ps : j'ai fait un menu objet-avec-enfant-potentiellement-unique qui fourni le lien vers l'enfant unique s'il existe plutôt que vers le parent (usage surtout rubrique). Si tu crois que c'est générique je le dépose.
Le 28/04/2010 04:44, Pierre Fiches a écrit :
oui et non l'automatisme sur la construction de la classe permet de
gagner du temps et de s'adapter après coup sans retouche à ce niveau. Le
changement d'ordre est comparativement moins génant même si ça suppose
une intervention manuelle parce qu'il n'est pas gérable automatiquement
une fois sur deux environ (cas des border left ou right pas forcément
appliqué à toute le collection, harmonie des couleurs..... Ceci dit
c'est sur qu'un identifiant fixe serait encore mieux (initiale de
l'objet_id_objet)
J'arrive toujours pas à voir mais bon, une classe CSS ça ne coute rien. 
On peut l'ajouter de toute façon.
ps : j'ai fait un menu objet-avec-enfant-potentiellement-unique qui
fourni le lien vers l'enfant unique s'il existe plutôt que vers le
parent (usage surtout rubrique). Si tu crois que c'est générique je le
dépose.
Ça c'est super utile, mais ça pourrait plutôt être une option au ou aux type(s) existant(s), non ? Ça éviterait d'allonger encore la liste des types, alors que ça existe déjà.
--
RastaPopoulos
Le 28 avr. 10 à 09:05, RastaPopoulos a écrit :
ps : j'ai fait un menu objet-avec-enfant-potentiellement-unique qui
fourni le lien vers l'enfant unique s'il existe plutôt que vers le
parent (usage surtout rubrique). Si tu crois que c'est générique je le
dépose.Ça c'est super utile, mais ça pourrait plutôt être une option au ou aux type(s) existant(s), non ? Ça éviterait d'allonger encore la liste des types, alors que ça existe déjà
j'ai choisi de faire un objet différent pour deux raisons :
- c'est pas sur qu'on veuille toujours ce comportement...
- performance : l'objet actuel impose un ou plusieurs test et il n'est probablement pas utile de l'appliquer à tous (notamment les objets dont la probabilité d'avoir un enfant unique est quasi nulle : cas du rayon allumettes chez un marchand d'allumettes )
Ceci dit on peut penser différemment, évidemment et/ou optimiser ce que j'ai déjà fait. J'ai trouvé deux anomalies dans la présentation des objets :
1 - le fait que la liste soit présentée inline complique considérablement la compréhension de chaque item (j'ai corrigé chez moi en css en passant les items à block, je trouve que c'est nettement plus ergonomique)
2 - dans cette liste le label est le titre de l'objet qui d'ailleurs est plus un pitch qu'un titre. Le descriptif n'est pas utilisé, alors qu'il pourrait fournir un éclairage supplémentaire ou complémentaire. C'est juste une observation, qui me conduit à proposer la réalisation d'une page d'aide spécifique à cette liste : aide qui pourrait fournir plus d'explications calculées d'après le xml...
@+
pierre
Le 28/04/2010 10:28, Pierre Fiches a écrit :
j'ai choisi de faire un objet différent pour deux raisons :
- c'est pas sur qu'on veuille toujours ce comportement...
Je ne comprends pas : si c'est une option d'un truc existant, ben quand tu le veux tu actives l'option et quand tu le veux plus tu l'enlèves, non ?
- performance : l'objet actuel impose un ou plusieurs test et il n'est
probablement pas utile de l'appliquer à tous (notamment les objets dont
la probabilité d'avoir un enfant unique est quasi nulle : cas du rayon
allumettes chez un marchand d'allumettes
Si c'est en option, ça ne doit faire les tests que si l'option est activée, donc aucune différence dans les perfs.
Ceci dit on peut penser différemment, évidemment et/ou optimiser ce que
j'ai déjà fait. J'ai trouvé deux anomalies dans la présentation des
objets :
1 - le fait que la liste soit présentée inline complique
considérablement la compréhension de chaque item (j'ai corrigé chez moi
en css en passant les items à block, je trouve que c'est nettement plus
ergonomique)
Tu as pas dû mettre à jour depuis un bail, parce que ça fait bien longtemps que les types d'entrées sont présentés les uns en dessous des autres.
2 - dans cette liste le label est le titre de l'objet qui d'ailleurs est
plus un pitch qu'un titre. Le descriptif n'est pas utilisé, alors qu'il
pourrait fournir un éclairage supplémentaire ou complémentaire. C'est
juste une observation, qui me conduit à proposer la réalisation d'une
page d'aide spécifique à cette liste : aide qui pourrait fournir plus
d'explications calculées d'après le xml...
La description est affichée lorsqu'on a sélectionné un type d'entrée et qu'on a fait "suivant". Ça ne sert à rien de l'afficher en permanence puisqu'une fois qu'une fois qu'on a lu la description d'un type, on sait normalement à quoi il sert, donc on a plus vraiment besoin de la description.
--
RastaPopoulos
Le 28 avr. 10 à 13:05, RastaPopoulos a écrit :
Le 28/04/2010 10:28, Pierre Fiches a écrit :
j'ai choisi de faire un objet différent pour deux raisons :
- c'est pas sur qu'on veuille toujours ce comportement...Je ne comprends pas : si c'est une option d'un truc existant, ben quand tu le veux tu actives l'option et quand tu le veux plus tu l'enlèves, non ?
- performance : l'objet actuel impose un ou plusieurs test et il n'est
probablement pas utile de l'appliquer à tous (notamment les objets dont
la probabilité d'avoir un enfant unique est quasi nulle : cas du rayon
allumettes chez un marchand d'allumettesSi c'est en option, ça ne doit faire les tests que si l'option est activée, donc aucune différence dans les perfs.
oui en effet
Ceci dit on peut penser différemment, évidemment et/ou optimiser ce que
j'ai déjà fait. J'ai trouvé deux anomalies dans la présentation des
objets :
1 - le fait que la liste soit présentée inline complique
considérablement la compréhension de chaque item (j'ai corrigé chez moi
en css en passant les items à block, je trouve que c'est nettement plus
ergonomique)Tu as pas dû mettre à jour depuis un bail, parce que ça fait bien longtemps que les types d'entrées sont présentés les uns en dessous des autres.
bizarre
2 - dans cette liste le label est le titre de l'objet qui d'ailleurs est
plus un pitch qu'un titre. Le descriptif n'est pas utilisé, alors qu'il
pourrait fournir un éclairage supplémentaire ou complémentaire. C'est
juste une observation, qui me conduit à proposer la réalisation d'une
page d'aide spécifique à cette liste : aide qui pourrait fournir plus
d'explications calculées d'après le xml...La description est affichée lorsqu'on a sélectionné un type d'entrée et qu'on a fait "suivant". Ça ne sert à rien de l'afficher en permanence puisqu'une fois qu'une fois qu'on a lu la description d'un type, on sait normalement à quoi il sert, donc on a plus vraiment besoin de la description.
étonnant, je vais voir à quelle version je suis...