6.3 Vue spécifique de document

La définition d'une nouvelle vue de document nécessite un contrôleur de vue et un template.

Le contrôleur de vue peut être omis. Dans ce cas, Dynacase fera appel au contrôleur de vue par défaut.

6.3.1 Le contrôleur de vue

Pour qu'une méthode du document soit utilisable en tant que contrôleur d'une vue, il est nécessaire de lui ajouter la phpDoc @templateController afin de se prémunir d'une éventuelle exécution arbitraire de code.

Les paramètres reçus par la méthode sont au nombre de 3 :

  • $target (string) : nom de la fenêtre graphique qui est utilisée pour les hyperliens ("_self" par défaut),
  • $ulink (booléen) : indique s'il faut générer les hyperliens (true par défaut),
  • $abstract (booléen) : indique s'il faut générer uniquement les attributs de la fiche résumé (false par défaut).

Par convention :

  • le fichier de template porte l'extension .xml,
  • son nom (en minuscule) détermine le nom de la vue,
  • la méthode associée doit porter le même nom (la casse du nom de la méthode n'est pas prise en compte).
    L'objet Layout est accessible au moyen de la propriété lay de l'objet courant ($this->lay).

Par exemple, considérons la méthode mySpecialView :

/**
 * default view for a family
 * @templateController special view
 * @return void
 */
function mySpecialView($target = "_self", $ulink = true, $abstract = false)
{
    $this->viewdefaultcard($target, $ulink, $abstract);
 
    $myItems = $this->getMultipleRawValues("my_items");
    $items = array();
    foreach ($myItems as $cle => $val) {
        $items[] = array(
            "itemValue" => $val
        );
    }
 
    $this->lay->setBlockData("ITEMS", $items);
}

Le template associé peut être :

MYAPP/Layout/myspecialview.xml
<ol>[TEXT:myapp:List of items]
[BLOCK ITEMS]<li>[itemValue]</li>[ENDBLOCK ITEMS]
</ol>

6.3.2 Vue spécifique de consultation

La vue spécifique d'un document doit retourner un fragment HTML qui est inclus dans le corps de la page HTML.

La vue personnalisée est toujours rendue encapsulée dans FDL:VIEWCARD, elle- même rendue au sein de FDL:FDL_CARD(sauf si l'option S est utilisée) . Aussi cette vue personnalisée doit générer un fragment qui est inséré dans le body de la page HTML.

+-------------------------------------------------+
| FDL:FDL_CARD                                    |
|-------------------------------------------------|
|                                                 |
|  <body>...                                      |
|                                                 |
|  +-------------------------------------------+  |
|  | FDL:VIEWCARD                              |  |
|  |-------------------------------------------|  |
|  |                                           |  |
|  |  <div>                                    |  |
|  |                                           |  |
|  |  +-------------------------------------+  |  |
|  |  | Vue spécifique de document          |  |  |
|  |  |-------------------------------------|  |  |
|  |  |                                     |  |  |
|  |  |                                     |  |  |
|  |  |                                     |  |  |
|  |  +-------------------------------------+  |  |
|  |                                           |  |
|  |  </div>                                   |  |
|  |                                           |  |
|  +-------------------------------------------+  |
|                                                 |
|  </body>                                        |
|                                                 |
+-------------------------------------------------+

Afin de définir une vue personnalisée, il est possible :

  • d'utiliser un contrôle de vue,
  • de spécifier une zone en paramètre HTTP : pour ce faire, il suffit de passer l'identifiant de la zone documentaire dans le paramètre zone de l'url d'accès au document,
  • d'indiquer la zone documentaire dans l'attribut defaultView du fichier CLASS de la famille pour avoir cette vue par défaut lors de la consultation.
public $defaultView='MYAPP:MYSPECIALVIEW'

6.3.2.1 Contrôleur par défaut

6.3.2.1.1 Définition du contrôleur par défaut

En l'absence de méthode correspondant à la vue, le contrôleur par défaut Doc::viewDefaultCard() est appelé.

Ce contrôleur est fait pour les vues de consultations et n'est pas adapté pour les vues de modification.

6.3.2.1.2 Utilisation des valeurs du document

Le contrôleur par défaut fait automatiquement appel aux méthodes Doc::viewAttr() et Doc::viewProp(). Elles initialisent les clés suivantes :

  • viewAttr va créer :
    • L_ATTRID pour chaque attribut : le libellé (traduit) de l'attribut,
    • V_ATTRID pour chaque attribut : la valeur (au format html) de l'attribut,
    • S_ATTRID pour chaque attribut : true si l'attribut est vide, false sinon
  • viewProp va créer :
    • ATTRID pour chaque attribut : la valeur brute de l'attribut,
    • PROPID pour chaque propriété : la valeur brute de la propriété,
    • V_TITLE une ancre vers le document lui-même avec son titre.

Note : Toutes ces clefs sont en majuscules.

Lors de l'utilisation d'un contrôleur personnalisé, il est possible d'appeler ces méthodes afin de générer les clés correspondantes. Il est également possible de définir d'autres clés en utilisant les différentes méthodes du Layout.

Attention : toutes ces clés respectent les visibilités : si la visibilité d'un attribut est H pour un utilisateur, les clés L_ATTRID et V_ATTRID sont des chaînes vides. S_ATTRID, pour sa part, n'est pas affecté par les visibilités.

Exemple d'un template sans contrôleur :

MYAPP/Layout/mysimpleview.xml
<h1>[V_TITLE]</h1>
 
<p>L'attribut [L_MY_TEXT] a la valeur : <strong>[V_MY_TEXT]</strong></p>

Dans cet exemple l'attribut MY_TEXT fait partie de la définition du document.

6.3.3 Vue spécifique de modification

Le template d'une vue de modification s'insère dans un formulaire HTML. Il est composé de champs de formulaire afin de permettre à l'utilisateur d'effectuer la saisie.

Il est aussi possible d'ajouter des css et des js spécifique (Se reporter au chapitre Moteur de template).

+-------------------------------------------------+
| GENERIC:GENERIC_EDIT                            |
|-------------------------------------------------|
|                                                 |
|  <body>                                         |
|                                                 |
|  +-------------------------------------------+  |
|  | FDL:EDITCARD                              |  |
|  |-------------------------------------------|  |
|  |                                           |  |
|  |  <form>                                   |  |
|  |                                           |  |
|  |  +-------------------------------------+  |  |
|  |  | Vue spécifique de formulaire        |  |  |
|  |  |-------------------------------------|  |  |
|  |  |                                     |  |  |
|  |  |                                     |  |  |
|  |  |                                     |  |  |
|  |  +-------------------------------------+  |  |
|  |                                           |  |
|  |  </form>                                  |  |
|  |                                           |  |
|  +-------------------------------------------+  |
|                                                 |
|  </body>                                        |
|                                                 |
+-------------------------------------------------+

6.3.3.1 Utilisation des champs de formulaire du document

Pour les vues de modifications de documents, le contrôleur par défaut n'est pas adapté car il ne fournit que des valeurs d'attributs et non des champs de saisie pour un formulaire.

Pour avoir l'équivalent du contrôleur par défaut en modification il faut utiliser la méthode Doc::editAttr. Cette méthode initialise les clés suivantes :

  • L_ATTRID pour chaque attribut : le libellé (traduit) de l'attribut, (entouré d'une balise <b/> si l'attribut est obligatoire),
  • V_ATTRID pour chaque attribut : un input pour l'attribut,
  • W_ATTRID pour chaque attribut : true si l'attribut est visible, false sinon.

Note : Toutes ces clefs sont en majuscules.

Attention : toutes ces clés respectent les visibilités : si l'attribut a une visibilité H (caché) pour l'utilisateur, la clé V_ATTRID génère un <input value="the value" type="hidden"/>. Si la visibilité est I (invisible) aucun champ n'est retourné. Les clés L_ATTRID ne sont pas affectées par la visibilité.

Lors de l'utilisation d'un contrôleur personnalisé, il est possible d'appeler ces méthodes afin de générer les clés correspondantes. Il est également possible de définir d'autres clés en utilisant les différentes méthodes du Layout.

6.3.3.2 Utilisation d'un contrôleur spécifique de modification

Le contrôleur de modification n'est applicable qu'au formulaire HTML.

/**
 * default edit for a family
 * @templateController special edit
 * @return void
 */
function mySpecialEdit($target = "_self", $ulink = true, $abstract = false)
{
    $this->lay->set("textValue", $this->getRawValue("my_text"));
    $textAttribute=$this->getAttribute("my_text");
    $this->lay->set("textLabel", $textAttribute->getLabel());
}

Le template associé peut être :

MYAPP/Layout/myspecialedit.xml
<h1>Modifier la valeur de [textLabel]</h1>
 
<input name="_my_text" value="[textValue]"/>
 

Le nom (attribut name) des champs de formulaire doit être précédé de _ (underscore) pour être pris en compte lors de la soumission de façon automatique. Sinon, il est possible de récupérer tout autre champ dans le hook preStore avec la fonction getHttpVars().

×