Bon bah ça a avancé depuis. demain je compte ajouter les types qu'il manque (assez rapide), rajouter l'entête de la map (aussi) ... mais bon comme on est jamais à l'abris de bug. Me restera alors la partie php.

Au fait, j'ai un truc que je voudrais corriger, j'ai une chaine de caractere dans mon code, avec genre 'message qui apparaitra devant le champ ... <br /> patati'. Et en fait le br il s'affiche tel quel, alors que moi je voudrais qu'il revienne à la ligne ? ça doit être tout con mais je vois pas.

Question : je mets la possibilité de supprimer une ligne après l'avoir ajouté ? (c'est dans mes plans mais je prefere demande quand même)

Grummfy > concernant Sortables, ce serait tres pratique, mais dans le code de la doc et des exemples je vois pas sur quoi est basé le classement. Un id ? en tout cas dans le code je vois pas. Parce que sur le générateur de map, chaque ligne à une id, donc soit quand on défile une ligne avant l'autre on interchange les idées, soit y a un champ hidden position ou autre qu'on interchange. Donc forcément quelque chose à échanger sinon je vois pas trop ...

D'après ce que je voix c'est basé sur l'id (dans l'exemple donné (l'id test))
enfin sinon c'est pas grave...

par contre à la fin, oublie aps de garder dans mootools que ce dont tu as besoin -> et regarde par rapport à la version présente dasn fsb si il faut ajouter des choses ou non ...

\r\n OU \n ?

Grummfy > Non pas de cette id que je parle.

BJ > ouais j'y ai pas pensé -_-', j'essayerais.

J'ai eu un peu de temps pour faire avancer le truc aujourd'hui, j'ai pu résoudre le bug sous opéra aussi.
Ce qu'il me reste à faire :
- la partie php (récupération des options et création du fichier xml)
- Creer les champs de parametrage de l'entete de la map.

Sinon voilà ce qui est fait pour le moment : http://bmoncef.tuxfamily.org/maps/maps.html
Hésitez pas avec les remarques, surtout pour le code JS je suis sur qu'il y a possibilité de le rétrécir ...

EDIT : me rend compte que j'ai pas testé avec IE, et qu'il y a apparemment un problème avec le JS, même si firebug et la console d'erreur d'opéra n'affichent rien comme erreur

Fignole le truc sous ff et opera, je pense que c'est un outil qu'on peut se permettre de ne pas chercher à tout prix à porter sur IE, au pire ça se verra après

Bon boulot pour le moment Il faudrait pouvoir intervertir les blocks entre eux, une fois créé.

Et aussi pouvoir en supprimer...

C'est un très bon début. J'ai pas du tout regarder le code, mais j'ai par contre quelques critiques sur l'interface (Je sais que ce n'est pas fini et je suppose que certaines de mes remarques sont prévues, mais je préfère le dire tout de même).

Concernant l'interaction globale d'ajout de champs, je ne procéderais pas tout à fait de cette manière.
A droite, au lieu d'avoir une liste de blocs de champs, je mettrais juste un aperçu de la MAP (avec les valeurs par défaut). A chaque champs, j'associerais des boutons éditer/supprimer et la possibilité de les réordonner par glisser/déposer.
Ensuite, pour la configuration d'un champ, à l'ajout et à l'édition, j'afficherais un bloc de la même manière que tu le fais actuellement, mais uniquement un seul, celui que l'on veut éditer. (voire, peut être, faire apparaître ce bloc sous forme de "popup" (à la manière de la signalisation de nouveau MP) grisant le reste et empéchant de d'interagir dessus comme une fenêtre modale, une fois éditer, la fenêtre disparaît)

Sinon autres remarques
- le type de champ de la partie droite d'édition des blocs, devrait être le même que ce que l'on glisse/dépose,
- précise ce que tu demande pour par exemple "Taille du champ texte" (Taille en pixels ?),
- afficher l'id d'un champ n'a pas d'intérêt
- "Direction de la liste" -> "Disposition ..." ou "Positionnement ...",
- Le nom de la ligne est un paramètre dont l'utilisateur n'a pas besoin. Demandes le "Nom du champ" et je mettrais en plus à coté (ou au niveau du résultat) une case à cocher "Ajouter le nom du champs dans le message", qui ajoutera automatiquement NomDuChamp : devant la résultat.
- faudrait trouver une autre formulation (j'ai pas d'idée pour le moment), pour le champ "résultat"


C'est juste que pour le moment, bien qu'un très bon début, je trouve l'interface et la création d'une map pas spécialement intuitive sauf pour ceux qui savent un peu à quoi ressemble la MAP en XML et donc ce qui est demandé.

C'est une bonne idée et ça me facilitera des choses ... En fait jusqu'ici je comptais attendre que toutes les lignes de la map soient créées avant de passer au php, mais avec ta disposition, pour faciliter les choses, faudra modifier le fichier xml à l'ajout de chaque ligne. ça me pose pas un problème en soit, mais je sais pas si ça ralentira le truc ou pas.

Sinon pour l'aperçu j'aimerais bien des idées, parce que je vois pas vraiment quoi afficher ... les options de la ligne ? ou juste un bloc comme ceux actuels qui rappelle qu'il y a une ligne de type x dans la map, avec possibilité de supprimer/modifier/trier ?


Bonne idée également, mais pour la popup ché pas, je trouve que ce serait mieux directement sur la page.


J'ai pas compris.

Je vois pas l'utilitée d'afficher le nom du champ dans le message.
Pour le reste c'est ok, vais en tenir compte.


Avec la proposition de disposition de Shekral, ce sera possible je pense. Avec l'actuelle, j'ai essayé mais j'y suis pas arrivé ...

Idem.

En fait, en y repensant, il y a 2 aperçus à afficher : celui de ce que va donner la MAP quand un membre sera en train de poster son message (ce que tu vois par exemple, ici quand tu veux signaler un bug) et celui du résultat de la MAP (i.e. le message final qui sera affiché dans le sujet) en prenant comme valeur celle par défaut des champs.

Je soumets juste l'idée d'une "fenêtre" modale, mais le principe serait surtout de n'avoir qu'un seul bloc d'édition affiché à la fois.


Les étiquettes que l'on glisse/dépose s'appelle "champ texte", "cases à cocher"... et dans le titre des blocs il y a type de champs "input", "checkboxes". Il vaut mieux garder la même terminologie et je trouve celle des étiquettes de gauches bien mieux.
C'est juste une idée, il est assez courant que pour le résultat du message on affiche quelque chose dans le genre :Et en fait on met le nom du champ devant sa valeur dans le message final, pour savoir à quoi elle correspond. Bien sûr, il arrive aussi qu'on ne veuille pas utilisé le nom du champs, mais formater l'affichage de la réponse autrement.

Oui mais là le générateur de maps ne fera pas que créer la map, va falloir aussi la parser comme si on était sur le forum entrain de poster ou de lire un sujet formatté à l'aide d'une map ...


En fait une fois que l'étiquette est déposée je ne recupères pas ce que tu vois affiché (champ texte, cases à cocher, etc.), mais juste ce qu'il y a dans les <span> qui apparaissent pas. Mais c'est simple à ajouter je le ferais.


Bah c'est à ça que sert le champ 'résultat' actuel, tu peux formatter ton message comme tu veux, en mettent Nom : %s ou desc : %s ou autre chose, peut-être du html aussi si Geno en a laissé la possibilité dans la class map.