Semantique autour d'un menu <ul><li>

Bonjour,


Voila je finalise une appli de gestion de contenu dont le menu est présenté comme ci-dessous

<div id="menu">
<h2>Système</h2>
<ul>
<li>Gestion des sections</li>
<li>Gestion des modules</li>
</ul>
<h2>Utilisateurs</h2>
<ul>
<li>Gestion de comptes</li>
<li>Gestion des types de comptes</li>
</ul>

ect....

</div>

en fait c'est le retour d'une requete SQL qui génére le code en fonction des droits des utilisateurs ..

ma question est de savoir si niveau sémantique le fait de mettre les noms des sections concernés par le bout de liste est correct.

je galère sur la boucle qui est autour du code donc si c'est à la rue je commence par changer çà..

merci de vos commentaires.

Je comprend pas trop ton problème. En fait tu veux savoir si systeme et utilisateurs entre <H2> ça fait beau ou pas d'un point de vue graphique?
Parce que je vois pas ce que la sémantique fait la dedans!

Ben si c'est un menu vertical oui si c'est un horizontal non.
Voilà c'est mon avis.

Tu veux faire comme le menu de gauche de wanadoo mais sans pouvoir cliquer sur les catégories, c'est ça?

l'aspet n'est pas le débat ici.

existe t'il une meilleure façon de "nomer" une liste que de le faire comme çà ?

Ben à toi de voir à quoi le titrage de ta liste correspond. S'il est logique ou non par rapport à ton contenu. Juste une chose que je vois : tu utilises "h2", donc ce serait des sous-titres directs après le titre de ta page ? sinon, peut-être doivent-ils être redescendus en h3 ou h4, selon lors rôle ou leur hiérarchie dans la logique du document.

Je ne sais pas s'il serait préférable d'utiliser une liste dans une liste. Bref, une liste à deux niveaux ?

Il s'agit après tout d'un seul menu, mais par lequel on peut gérer plusieurs modules groupés par catégorie.

Voilà Merkel c'est ce genre de question que je me pose....


en fait il s'agit bien d'un menu unique avec x sections en fonction des utilisateurs connectés.


arf... je ne sais pas je vais étudier la liste imbriqué çà semble mieux.

merci pour ce rafraîchissement.

On peut se demander s'il ne s'agirait pas là d'une utilisation possible d'une liste de définitions... ce qui allègerait d'ailleurs le code en

<dl id="menu">
<dt>Système</dt>
<dd>Gestion des sections</dd>
<dd>Gestion des modules</dd>
<dt>Utilisateurs</dt>
<dd>Gestion de comptes</dd>
<dd>Gestion des types de comptes</dd>

</dl>

Il faudrait se demander pour cela si, par exemple, "Gestion des sections" et "Gestion des modules" définit bien ce que tu entends par "Système". Pourquoi ne pas changer en Gestion du système ->Sections;Modules si c'est le cas?
Modifié par Gilles (30 Aug 2005 - 16:44)

> Gilles : yep pas mal non plus çà !


alors j'ai de grande catégories dans le backoffice


les paramètres systèmes, utilisateurs, le contenu, forums ect.
et des liens sous forme de liste pour chaque...


j'aime bien aussi la liste de définition c'est même idéale je penses...


je test avec mes scripts.


MERCI !!!!!!

Personnellement, je préfère une liste à deux niveaux qu'une liste de définitions. Je sais bien que dans les specs et ailleurs, l'utilisation possible d'une liste de définitions est très large et floue. Ca permet beaucoup de liberté.

Cependant, je me suis toujours dis que les listes de définitions avait pour but de définir des éléments (élément dans le DT), comme un dictionnaire par exemple dans lequel on retrouve une liste de mots et leur X définition(s) pour chacun. Ou encore dans une page de documentation sur une application expliquant ce que chaque fichier de l'application fait, ou à quoi sert chaque variable, ou encore un album photo avec titre et description pour chaque photo. Mais j'ai un peu de mal à accepter de faire des menus de navigation avec les listes de définitions. J'ai l'impression, au fond de moi, que ce n'est pas leur rôle. Les DD, dans ce cas, ne définissent pas vraiment ce qui se trouve dans le DT. Une liste imbriquée me semble plus appropriée.

Ceci n'engage que moi. Libre à chacun d'utiliser ou non les listes de définitions pour leurs menus, et peut-être du même coup, essayer de me convaincre que c'est tout à fait logique de les utiliser. Après tout, je ne dis pas que c'est mal, juste que cela ne me semble pas être leur rôle de départ.
Modifié par Merkel (30 Aug 2005 - 17:46)

une chose est sur c'est que par rapport à mon appli, le code est plus simple à généré pour rester valide en même temps...

je rame avec une requete (group by) alors je trouve des solutions ici et la ...
Si je me souviens il y aune fonction super confort sous Coldfusion pour regrouper les infos provenant d'une requete...

genre je boucle d'une façon spécifique pour avoir une publication de résultat directement présenté groupé sur une colone ?

mais en ASP j'suis en tongue..... enfin

Oui mais en même temps, tu ne devrais pas choisir ton code html (au niveau sémantique) selon tes limitations techniques et/ou de tes connaissances. Il vaudrait mieux que tu pousse un peu plus tes connaissances côté serveur afin de générer le code que tu veux.

Ceci dit, pour l'instant, tu peux toujours utiliser une liste de définitions. La terre n'explosera pas et comme je le disais, ce n'est pas mauvais. C'est juste que ca n'entre pas dans ma propre définition de ce qu'est sémantiquement une liste de définitions.

héhéhé


en fait j'ai trouvé comment faire pour générer proprement une liste à plusieurs niveaux en partant de la même requete..


j'ai donc le choix arf c'est bon d'être libre.....


PS > Merckel çà bouge le monde de la fusion à froid ? y'a du nouveau ? c'est pas franchement mis en avant chez macromedia

ernstein a écrit :

PS > Merckel çà bouge le monde de la fusion à froid ? y'a du nouveau ? c'est pas franchement mis en avant chez macromedia

Oui ca bouge. Ils viennent de sortir Coldfusion MX 7. C'est dans la suite STUDIO 8, sur leur site.

Sinon, ouais ca roule au boulot. Mais là je développe une application Delphi en local qui communique avec mes WebServices Coldfusion.

je penses vraiment prendre ne licence studio 8 c'est une version developpeur qu'il y a dedans ?


mon hébergeur support cold....

Si ton hébergeur supporte déjà le Coldfusion, pas la peine d'acheter quoique ce soit. Tu peux créer des pages .cfm, en écrivant du code CFML (Coldfusion Markup Language), et ca devrait rouler. Tu peux utiliser l'éditeur de ton choix.

Studio 8 contient un paquet de logiciels et Coldfusion MX 7 en fait partit.
Modifié par Merkel (30 Aug 2005 - 18:32)

Jaimerais avoir un serveur de dev local....

c'est un enfer sinon, + l'admin pour gérer les bases...


à propos MySQL est supporté ?

MySQL est supporté, oui.

Je sais qu'il existe gratuitement, sur le site de Macromedia, une version de Coldfusion pour le développement. Tu peux le mettre légalement sur un serveur de développement, mais lorsque tu veux le mettre sur un serveur de production, il faut payer la license.

cffaq.com a écrit :

ColdFusion can be bought from Macromedia directly at http://www.macromedia.com/buy/ and from resellers (information at that same URL). You can also download a trial version by going to http://www.macromedia.com/software/coldfusion/. The trial version is the full product and will run for 30 days from the time of installation. After 30 days it reverts to a Developer Edition which may be used for ongoing development.

Si tu veux en savoir plus sur Coldfusion, je t'invites à visiter www.cffaq.com ou directement le site de Macromedia.
Modifié par Merkel (30 Aug 2005 - 18:48)

Merci j'y cours

J'ai réfléchi à cette histoire de liste de définitions... en fait, je pense que c'est quand même adapté.

On peut en effet se poser la question: "Qu'est-ce que la gestion de mon système?" et répondre par: "c'est la gestion des modules et la gestion des sections". Cela définit bien ce qu'est, dans le contexte de ce site, la gestion du système.

Je n'ai pas l'impression de jouer avec la définition de la liste de... définition . Il n'est nulle part écrit qu'une telle liste doit nécessairement fournir des définitions universelles. Elles peuvent être propres à un contexte particulier.
Modifié par Gilles (31 Aug 2005 - 10:04)

C'est la le propre même des définitions... !!!