Semantic MediaWiki : Différence entre versions

De Open Source Ecologie
(Formulaire)
(Formulaire)
Ligne 115 : Ligne 115 :
 
  <nowiki>{{{end template}}}</nowiki>
 
  <nowiki>{{{end template}}}</nowiki>
  
On voit ainsi clairement le modèle qui a été utilisé (le [[template:profil|Template "Profil"]]). La mise en page est du type tableau, ce qui explique la mise en page du type " {| ....|.... |-....|....|} " (voir plus d'info sur les tableaux sur le [https://www.mediawiki.org/wiki/Help:Tables/fr wiki d'aide de mediawiki]. Enfin, le nom des champs (ce que verra l'utilisateur du formulaire) est précédé d'un point d'exclamation, et les champs dans lesquels les utilisateurs vont rentrer leur valeurs sont donnés entre triple accolades également. Par exemple, <nowiki>{{{field|Nom prénom, ou pseudo|mandatory}}}</nowiki> est un champ (type field), la propriété dans laquelle va être stockée la valeur est "Nom prénom, ou pseudo" et il est mentionné en plus "mandatory" (rendant ce champ obligatoire). Pour plus de détails sur liste des paramètres d'un champ, se référer aux liens mis en début de page {{@|Antoine|De quels liens parles-tu précisément ?}} {{@| Cyril | Des liens disponibles en haut de page (en particulier de MediaWiki) et de cette section après recherche : [https://www.mediawiki.org/wiki/Extension:Form#Form_definitions Définition des paramètres des champs d'un formulaire])}}
+
On voit ainsi clairement le modèle qui a été utilisé (le [[template:profil|Template "Profil"]]). La mise en page est du type tableau, ce qui explique la mise en page du type " {| ....|.... |-....|....|} " (voir plus d'info sur les tableaux sur le [https://www.mediawiki.org/wiki/Help:Tables/fr wiki d'aide de mediawiki]. Enfin, le nom des champs (ce que verra l'utilisateur du formulaire) est précédé d'un point d'exclamation, et les champs dans lesquels les utilisateurs vont rentrer leur valeurs sont donnés entre triple accolades également. Par exemple, <nowiki>{{{field|Nom prénom, ou pseudo|mandatory}}}</nowiki> est un champ (type field), la propriété dans laquelle va être stockée la valeur est "Nom prénom, ou pseudo" et il est mentionné en plus "mandatory" (rendant ce champ obligatoire). Pour plus de détails sur liste des paramètres d'un champ, se référer aux liens mis en début de page {{@|Antoine|De quels liens parles-tu précisément ?}} {{@|Cyril| Des liens disponibles en haut de page (en particulier de MediaWiki) et de cette section après recherche : [https://www.mediawiki.org/wiki/Extension:Form#Form_definitions Définition des paramètres des champs d'un formulaire])}}
  
 
* Il est possible de voir la liste des profils créés par ce formulaire sur le [[Trombinoscope]].
 
* Il est possible de voir la liste des profils créés par ce formulaire sur le [[Trombinoscope]].

Version du 22 avril 2017 à 14:37

La sémantiqueW MediaWiki permet une collaboration entre un Wiki et sa base de donnéesW. En particulier, elle permet d'organiser les données enregistrées.

Sur cette page, les termes de propriété, modèle et formulaire seront éclaircis dans un premier temps. Puis, au travers d'exemples tirés directement de ce Wiki, nous verrons comment rechercher, trier et afficher les données enregistrées.


Navigation rapide


Sémantique existante

Création


Quelques liens et conseils préalables

Il est possible à tout moment (et sur tous les Wikis) d'avoir accès aux codes en cliquant sur "Modifier" ; il ne faut pas hésiter à s'inspirer, comprendre le fonctionnement ou l'affichage visible sur les autres Wikis.

Définitions

Propriété

Définir une propriété

Les propriétés peuvent être vues comme les "variables" du wiki ; une propriété va prendre un type de valeur défini par l'utilisateur. Par exemple, si la propriété "Prénom" est créée, elle va pouvoir stocker des valeurs comme "Pierre", "Lucas" ou "Clémence" (notamment au travers de formulaires, voir plus loin). Ainsi, lorsqu'il sera souhaité par la suite d'afficher la liste des prénoms, ou plus précisément la liste des prénoms "Pierre" enregistrés, il suffira d'utiliser la propriété Prénom (au travers d'un test d'égalité proche de ce que l'on retrouve dans de nombreux langages informatiques).

Type

De plus, il est possible d'imposer un type à une nouvelle propriété créée : dans le cas général, pour éviter de contraindre l'utilisateur lorsqu'il rentre une valeur dans une propriété, il est commode d'utiliser les types "text" ou "page" (en fonction du besoin). Mais il est possible de choisir des types comme Number ou E-mail ; ainsi, lors de la saisie, l'utilisateur se verra refuser la valeur si elle ne correspond pas au format attendu.

Par exemple, si la propriété Age est du type Text, elle acceptera les valeurs "25", "douze ans" ou encore "voiture" et sera difficilement exploitable par la suite (si l'on souhaite par exemple voir les personnes âgées de plus de 20 ans). Si elle est du type Number, le tri sera alors possible.

Restreindre les valeurs

Enfin, il est possible de restreindre les choix à une série de valeurs au moment de définir la propriété ; à noter qu'il est toujours possible d'ajouter ou de supprimer des valeurs en modifiant la propriété par la suite. Par exemple, on peut définir la propriété "Lancer de pièce" et imposer les valeurs "Pile" et "Face" seule. Encore une fois, restreindre des valeurs sera utile lors des possibles tris à effectuer par la suite (n'afficher que les personnes qui ont fait "Pile", c'est à dire où la propriété Lancer de pièce=Pile).

Remarque importante : Attention à la syntaxe des valeurs "permises" par la suite : autoriser "PILE" et "face" rédigés ainsi a pour conséquence de ne renvoyer aucun résultat lors des requêtes comportant les tests d'égalités Lancer de pièces = "Pile", "pile", "Face" ou encore "FACE". Il est donc judicieux d'adopter la même syntaxe au sein d'une (ou de toute) propriété. La convention adoptée sur ce Wiki est la suivante : "première lettre en majuscule, reste en minuscule".

Modèle

Lien de création d'un modèle (Template)

Le modèle (ou Template) peut-être vu comme un patron. Typiquement, toute partie de texte ou de mise en page apparaissant plusieurs fois peut être mis sous la forme d'un modèle. Les zones variables d'un modèle peuvent ainsi être mises en "paramètres".

Par exemple :

Sans l'utilisation d'un modèle Avec l'utilisation d'un modèle
Profil utilisateur : Antoine

Ceci est le profil de Antoine sur le site de OSE. Il est actuellement âgé de 21 ans.

Il est possible de créer son propre profil, ou de modifier son profil ici.

{{Profil utilisateur|Antoine|21}}


Après la création du Template "Profil utilisateur", ces deux codes affichent le même résultat. Ici, il y a 2 paramètres : "Antoine" et "21". On verra plus tard qu'il est encore possible d'optimiser cette écriture si "Antoine" possède déjà un profil enregistré avec son âge. Les paramètres lors de la définition du Template apparaissent entre triple accolades. Ainsi, dans notre exemple, le Template "Profil utilisateur" serait défini ainsi :

Profil utilisateur : {{{1}}}
Ceci est le profil de {{{1}}} sur le site de OSE. Il est actuellement âgé de {{{2}}} ans.  
Il est possible de créer son propre profil, ou de modifier son profil ici.

On remarque alors que sur une page affichant plusieurs fois différents "profils utilisateurs", le gain de temps et de place est important.

A noter qu'il est possible de combiner ces modèles avec des requêtes, d'autres modèles, etc...

Formulaire

Lien de création d'un formulaire.

Les formulaires font le pont entre l'utilisateur et la base de données. Un formulaire s'appuie sur un modèle et des propriétés (à définir au préalable). L'utilisateur stocke alors des valeurs dans des propriétés, le tout organisé dans un modèle. Pour le formulaire "Profil", la partie à identifier est la suivante (le reste étant des explications, ou de la mise en page) :


{{{for template|Profil}}}
{| class="formtable"
! Nom prénom, ou pseudo: 
| {{{field|Nom prénom, ou pseudo|mandatory}}}
|-
! Avatar: 
| {{{field|Avatar}}}
|-

...

! Linkedin:
|{{{field|Linkedin}}}
|}
{{{end template}}}

On voit ainsi clairement le modèle qui a été utilisé (le Template "Profil"). La mise en page est du type tableau, ce qui explique la mise en page du type " {| ....|.... |-....|....|} " (voir plus d'info sur les tableaux sur le wiki d'aide de mediawiki. Enfin, le nom des champs (ce que verra l'utilisateur du formulaire) est précédé d'un point d'exclamation, et les champs dans lesquels les utilisateurs vont rentrer leur valeurs sont donnés entre triple accolades également. Par exemple, {{{field|Nom prénom, ou pseudo|mandatory}}} est un champ (type field), la propriété dans laquelle va être stockée la valeur est "Nom prénom, ou pseudo" et il est mentionné en plus "mandatory" (rendant ce champ obligatoire). Pour plus de détails sur liste des paramètres d'un champ, se référer aux liens mis en début de page @Antoine [1] @Cyril [2]

  • Il est possible de voir la liste des profils créés par ce formulaire sur le Trombinoscope.

Requêtes

Les requêtes peuvent être de plusieurs types. Deux types de requête sont principalement utilisés ici : la requête #ask et la requête #show. A l'aide des définitions données ci dessus et des exemples implémentés, nous allons en expliquer leur fonctionnement. Il suffira de cliquer sur "Modifier" des liens ci dessous pour voir la requête. @Antoine [3]

Pour plus d'informations, se référer au document suivant : Requêtes de recherche sémantique

Affichage des membres des différents cercles

#ask:[[Cercle::Budget & financement]] est une requête qui ne va retenir que la valeur Budget & financement de la propriété Cercle. Dans le cas d'un test d'égalité entre une propriété (Cercle) et une de ses valeurs (Budget & financement), la syntaxe est "2 fois deux points" comme visible ci dessus.

La propriété Cercle apparaît dans le formulaire "Profil", donc cette propriété est reliée aux autres propriétés du formulaire "Profil". Ainsi, il est possible de faire apparaître les valeurs de ces autres propriétés, comme le pseudo : |?Pseudo=Nom ou pseudo. La barre verticale est due à la mise en page des résultats (tableau). Ici, on questionne la propriété "Pseudo" des résultats retenus après la requête #ask. La partie =Nom ou pseudo permet de renommer la colonne du tableau. La même mécanique est reproduite pour le "Groupe Local" et les autres "Cercles".

Enfin, en dessous, de la mise en page : par exemple, |headers=show permet l'affichage des titres des colonnes et |sort=Pseudo sort les résultats par ordre alphabétique des pseudos.

Glossaire


Le glossaire est accessible ici : Glossaire


Formulaire & Propriétés


Ce formulaire permet de relié les propriétés (qui ont été créées en parallèle) suivantes : Définition, Description, Fournisseur, Lien, Compétences et Projet.

A noter que la propriété Compétences était déjà présente dans le formulaire "Profil" : elle est donc reliée aux nouvelles propriétés énoncées ci-dessus mais également à celles de Profil. On observe des paramètres de champs supplémentaires :

  • input type= impose un nouveau type de champ (listbox pour un menu déroulant, textarea pour un champ large,...)
  • placeholder= fait apparaître un message grisé disparaissant au clic de l'utilisateur.
  • default= assigne une valeur par défaut au champ, pratique pour les filtres (de plus, je l'utilise car lorsque qu'un champ est laissé vide, il y un décalage entre valeur stockée et champ. On a alors la valeur du champ stockée dans la mauvaise propriété).

Ce formulaire permet ainsi de stocker les définitions des utilisateurs. En l'associant à la catégorie Définitions, il est possible de voir toute les définitions rentrées.

Référencer les définitions


Le Template Ref est relativement court : {{ #tag:ref| {{ #show: {{{1}}} | ?Description }} }}. L'appel à ce Template est simplement : {{Ref|Terme à définir}}.

Le #tag:ref| met juste en référence le contenu qui le suit.

La requête {{ #show: {{{1}}} | ?Description }} est une requête qui a l'avantage d'être inline, c'est à dire qu'aucune mise en page ne lui est associée : le résultat apparaît en brut dans le texte. Dans ce cas, on demande de "montrer" la valeur de la propriété Description du terme qui a été mis en paramètre. Si je veux la définition de "Voiture", en écrivant {{Ref|Voiture}}, je mets en référence la description du terme "Voiture".

A noter que la propriété associée à la valeur "Voiture" (qui est Définition) n’apparaît pas, contrairement à une requête #ask (on on aurait eu #ask:[[Définition::Voiture]])


Afficher les résultats


Ensemble du Glossaire :

Il s'agit d'une requête #ask comme visible précédemment, la seule différence étant qu'il n'y a pas de "Définitions" particulières à afficher ; pour toute les afficher, on utilise donc #ask:[[Category:Définitions]] qui va afficher toute les définitions de la catégorie "Définitions". Puis on affiche la propriété Definition et Description de ces entités.


Par Projet ou par Domaine de compétences :

Plutôt que de "copier-coller" une même requête, on va utiliser un modèle. La démarche étant analogue entre un tri par projet ou par domaine de compétence, l'explication sera faite pour le tri par Projet.

Le Template associé est appelé de la manière suivante : {{AffichageDef|Nom du projet|Page_Du_Projet}}. Dans un premier temps, on distingue le cas où une page est associée à un projet :

{{#if: {{{2}}} | La page associée à {{{1}}} est disponible [[{{{2}}}|ici]]. | }}

La formulation {{#if: contenu | Réponse 1 | Réponse 2}} est plutôt pratique : si le "contenu" existe/est non vide, il renvoie la réponse 1 ; sinon, il renvoie la réponse 2. Ainsi, dans notre cas, soit l'utilisateur rentre la page (paramètre 2) et dans ce cas une phrase avec le lien généré est renvoyer, soit il ne rentre rien et rien n’apparaît.

Ensuite, on retrouve un système de tri classique : #ask:[[Projet::{{{1}}}]]. Le paramètre 1 est le nom du projet, donc une valeur de la propriété Projet. (Pour le tri par domaine de compétence, on utilise juste la propriété "Compétence" mis sur une page dédiée, par exemple "Classification_des_définitions_d'Agriculture/Maraîchage/Permaculture").

Par la suite, il sera possible d'afficher les définitions d'un groupe de domaine de compétences (actuellement, 3 groupes existent : "Sciences exactes et naturelles", "Technologie et Sciences appliquées" et "Sciences Humaines et Sociales"). La démarche est analogue, une manière de faire serait de créer une propriété "Sciences exactes et naturelles" pouvant prendre les valeurs qui sont en lien avec ce groupe (à savoir "Physique • Mécanique • Ecologie" actuellement) et d'afficher les définitions filtrées par cette nouvelle propriété. Le résultat sera alors équivalent à un tri "Compétences = "Physique" ou "Mécanique" ou "Ecologie".

Catégoriser les demandes par discipline

  • Voir la catégorie @Mécanique

Sur la page associée à la catégorie Mécanique, la requête de tri est un peu particulière. Comme dit précédemment, la propriété "Compétences" est présente dans le formulaire "Profil" et le formulaire "Definir". Ainsi,un simple filtrage des données de tous les formulaire ayant la valeur "Mécanique" pour la propriété "Compétences" ne suffisait pas. D'où :

#ask:[[Compétences::Mécanique]][[Pseudo::!NULL]]

Dans ce cas, on impose aux résultats d'avoir la propriété Compétences valant Mécanique ET la valeur de la propriété Pseudo non vide. Le formulaire de définition n'utilisant pas la propriété "Pseudo", la valeur de "Pseudo" est nécessairement nulle. Remarque : d'autres propriétés sont exclusivement dans le formulaire "Profil" et aurait pu être utilisées ; néanmoins, comme le but est d'afficher les noms des membres ayant des compétences en Mécanique, il est plus cohérent (et moins risqué pour la suite) d'imposer une condition sur le champ "Pseudo".

Pour le dire autrement, remplacer "Groupe local" par "Pseudo" aurait fonctionné, mais rien n'assure qu'un formulaire futur fasse apparaître la propriété "Groupe local" indépendamment des individus ; une partie des résultats serait alors inutile.

Remarque : le Template utilisé est le Template @, utilisé précédemment pour les "personnes".


Projet de Nomenclature automatisée (V1)

L'objectif de l'implémentation d'une Nomenclature dans le Wiki d'Open Source Ecologie est d'obtenir un détail de chaque pièce, sous ensemble et ensemble d'éléments d'un projet tout en les interconnectant. A terme, la saisie doit être simplifiée pour l'utilisateur tout en intuitant, si possible, les connections père-fils des différents ensembles et en attribuant un nom en respectant certaines conventions. Plus de détails ci dessous (partie Objectifs et Améliorations souhaitées).

Version actuelle et défauts

Il est possible de tester le parcours d'un élément à un autre (par exemple depuis cet item : Châssis)

Propriétés utilisées, modèle et formulaire de saisie

Propriété Rôle / But
Pere item Type Number. Cette propriété prend pour valeur la référence item du père de l'item concerné. C'est avec cette propriété que les liens père-fils se font.
Num item Type Number. Cette propriété prend pour valeur la référence de l'item. Voir les attentes concernant cette propriété plus loin.
Niveau Type Number. Le niveau s'incrémente avec les générations. L'assemblage complet correspond à la racine (de niveau 1, tout comme la documentation annexe. Le niveau 0 est réservé au projet en lui-même.) Ainsi, le niveau d'un item = niveau +1 de son père.
Num item fils Type Number. Même fonctionnement que Pere item en sens inverse, mais loin d'être indispensable en réalité puisque la propriété Pere item fait déjà le pont entre les éléments. Néanmoins, utilisé actuellement pour lister les fils tant que la saisie de la BOM n'est pas complète.
Bubble Type Number. Cette propriété prend en valeur la "bulle" des éléments (voir fichier Excel)
Détails Type Text. Rapide descriptif de l'objet.
Lien Type lien. Propriété pré-existante, utilisé 4 fois dans le formulaire de saisie d'un item, mais par la suite un seul lien ne sera utile : lien 3D.

Le formulaire de saisie est accessible ici : Form:Item.

Le modèle utilisé est visible ici : Template:Item

Affichage existant et explications

En bas de chaque page item créée, le Template Affich item a été utilisé ; il prend actuellement pour unique paramètre le nom/la description de l'item (depuis la propriété "Détails"). Le fonctionnement de ce Template est détaillé ci dessous. Il est découpé en 3 parties :

Les caractéristiques de l'item {{{1}}} sont les suivantes :
{{#ask:[[Détails::{{{1}}}]]
|? Pere item
|? Num item fils
|? Détails 
|? Bubble
|? Niveau
|searchlabel=… autres résultats
|class=sortable wikitable smwtable
}}

Cette première partie n'est pas réellement utile, elle servait en réalité dans un premier temps de test, pour comparer les valeurs affichées par ce tableau avec celles obtenues juste au dessus dans la page de l'item concerné.


{{#ifeq: {{#show:{{{1}}}| ?Niveau}} | 1 | Cet élément prend racine dans le projet [[DIY HD]] |  
Le père de cet élément possède les caractéristiques suivantes : 
{{#ask:[[num item::{{Père| {{{1 }}} }} ]] 
|? Détails 
|? Bubble
|? Niveau
|searchlabel=… autres résultats
|class=sortable wikitable smwtable
}}
}}

Cette partie a pour but d'afficher le père de l'item concerné. La première ligne vérifie si le niveau de l'item concerné est égal à 1 ; en effet, si c'est le cas, son père est niveau 0, c'est à dire qu'il ne s'agit pas d'un élément mais du projet (la racine). Ainsi, dans ce cas, on renvoie un lien vers le projet concerné. Comme l'unique projet à l'heure actuelle concerné par la nomenclature est le DIY HD, il est directement rentré dans le Template, mais par la suite, il est possible de mettre cette valeur en paramètre.

Si le numéro de l'item est différent de 1, on questionne alors le père de l'item concerné. Le Template Père se contente de renvoyer le numéro item du père de l'item concerné, c'est à dire son nom/sa référence. Ainsi, dans la requête #ask, on questionne bien l'item ayant pour numéro item le numéro item du père de l'item concerné. On affiche donc ses caractéristiques.


{{#if: {{#show:{{{1}}}| ?Num item fils }} | 
Et en voici la liste de ses fils :
{{#ask:[[Pere item::{{#show:{{{1}}}| ?Num item }}]]
|? Détails 
|? Bubble
|searchlabel=… autres résultats
|class=sortable wikitable smwtable
}}
| Cet élément ne possède pas de fils }}

Enfin, dans cette dernière partie, on effectue un test similaire à celui ci dessus. En effet, la première ligne questionne la propriété Num item fils ; si elle est vide pour l'item concerné, il n'y a rien à afficher/l'item n'a pas de fils. Une valeur vide renvoie alors la phrase "Cet élément ne possède pas de fils".

Sinon, on affiche ses fils. Il a été choisi de passer par la propriété Pere item. Ainsi, #ask:[[Pere item::{{#show:{{{1}}}| ?Num item }}]] n'affiche que les élément ayant la valeur du père (Pere item) dans leur numéro d'item (Num item). C'est la même mécanique en inversé du test précédent pour l'affichage du père. On en affiche alors ses/leurs caractéristiques.


Remarque : Dans toute les pages où ce Template est appelé, le premier paramètre peut être remplacé par un {{PAGENAME}}.

Objectifs & Améliorations souhaitées

De nombreux points sont à corriger. En voici un début de liste. Certaines corrections n'ont pas été effectuées pour donner une idée du système déjà existant.

  1. Par la suite, les propriétés Pere item, Num item et Num item fils devront être de type Text. En effet, le format pour nommer les différents éléments sera du type "PJT-STD-123".
  2. Ce nom permettra de caractériser les différents items. Dans l'exemple ci dessus, PJT peut correspondre à un code projet, STD à un code "standard" ou à un code "méthode d'usinage". La dernière partie devrait idéalement fonctionner en auto-incrément. Ainsi, lors de la saisie, l'utilisateur séléctionne les 2 premiers paramètres du nom de l'item, le 3ème étant automatiquement généré par rapport aux noms déjà existant.
  3. Par ailleurs, il serait souhaitable que ce nom soit celui affiché en entête de page item (par exemple, dans le cas de la Poutre_inférieur_gauche_(prolongée), le titre de la page est actuellement "Poutre inférieur gauche (prolongée)").
  4. Une incrémentation automatique de la propriété "Niveau" d'un item sachant le père (dans le formulaire de saisie).
  5. Après avoir implémenté un tel système de nomenclature, il serait pratique de pouvoir "automatiser l'enregistrement" des items dans la base de données à partir du fichier excel déjà existant de la nomenclature.


Projet de Nomenclature automatisée (V2)

Test d'une version modifiée de la Nomenclature.

Tout d'abord, 4 formulaires et 4 modèles reliés distincts (il est possible de créé un modèle commun qui sera appelé dans les 4 modèles avec 1 paramètre) ont été créés. Il permettent d'obtenir la première partie du nom "normalisé" de l'item. Dans cet exemple, les 2 lettres (A et B) sont la première partie du nom, et les deux chiffres (1 et 2) la seconde. Une troisième partie correspond à une incrémentation, par rapport à tous les termes du couple choisi. Il y a donc 4 propriétés, associées à ces 4 systèmes d'incrémentation indépendants, qui ont été créées (respectivement Inc A-1, Inc A-2, Inc B-1 et Inc B-2). Le choix du formulaire permet de pré-remplir le premier champ pour accéder au formulaire et également d'afficher la valeur maximum de la propriété d'incrémentation pour prendre la suivante (et ainsi s'assurer que ce nom n'existe pas au moment de la création).

Le même système de lien père-fils à été utilisé pour le parcours d'une page à l'autre, moyennant quelques modifications, en particulier dans le template "Affich item" (test via le #if pour l'affichage des fils).

Affichage du maximum et préremplissage

On s'intéresse au formulaire A-1.

{{#ask: [[Category:BOM A-1]]
| ?Inc A-1
| format=max
}}

On questionne bien la catégorie que l'on souhaite (BOM A-1) et on demande la valeur maximale de la propriété "Inc A-1" à laquelle il faut ajouter +1.

Le champ avant le formulaire est pré-rempli à l'aide de "default value=" placé dans le champ souhaité : {{#forminput:form=BOM A-1|default value=A-1-}} (Remarque : dans un formulaire de saisie, pour pré-remplir un champ, il faut simplement écrire "default=")

Propriétés ajoutées au formulaire de saisie

Lien père-fils pour la création d'un arbre

Pistes à exploiter

Liste de problèmes encore existants

  • Ajouter directement dans le champ pré-rempli la valeur de l'incrémentation (i.e. du max +1). Laisser cette étape de validation est nécessaire (notamment pour appeler une pièce déjà existante et la modifier depuis un formulaire).
  • L'utilisation de la fonction "tree" permettant l'affichage en arborescence des pièces est à perfectionner. Dans un premier temps pour faire apparaître les fils d'un élément apparaissant 2 fois (voir Nomenclature) puis, dans un second temps, en modifiant directement la mise en page imposée par "tree" (et le faire apparaître sous la forme d'un tableau)
  • Ajouter la propriété Lien au(x) formulaire(s), ainsi que les propriétés (à créer) "intendance" (permettant de différencier le même item à des endroit différents de l'arborescence)
  • @Antoine : De quels liens parles-tu précisément ?
  • @Cyril : Des liens disponibles en haut de page (en particulier de MediaWiki) et de cette section après recherche : Définition des paramètres des champs d'un formulaire)
  • @Antoine : Comme tu as utilisé les balises nowiki, je propose de supprimer cette dernière phrase
  • feedback
    MediaWiki Appliance - Powered by TurnKey Linux