La balise racine urls contient autant de balises entrypoint que de points d'entrée disponibles dans votre application.

Chacune de ces balises a un attribut name indiquant le nom du point d'entrée (sans l'extension .php), ou plus exactement, son chemin, relatif à la valeur du basePath dans la configuration générale. Et vous ajouterez éventuellement un attribut default indiquant si ce point d'entrée est celui par défaut pour le type de requête en question.

Il doit également y avoir un attribut type, qui indique le type de point d'entrée, et vaut donc classic, xmlrpc, jsonrpc etc.. Si cet attribut n'est pas présent, la valeur par défaut est classic.

Pour des raisons de compatibilité avec les versions précédentes de jelix, les balises entrypoint peuvent avoir d'autres noms. Leur nom exact précise le type de requête auquel ils sont affectés :

• classicentrypoint pour les requêtes classiques
• xmlrpcentrypoint pour du xmlrpc
• etc ...

Mais cet usage est dorénavant obsolète.

Chaque point d'entrée définit une ou plusieurs formes d'URLs possibles, sachant que celles qui ne sont pas définies seront acceptées lors d'une requête sur un point d'entrée spécifié "default".

Spécifier une forme d'URL complète ¶

   <url pathinfo="/foo/bar" module="hello" action="default:world" />

   <url pathinfo="/articles/:rubrique/:id_art" module="cms" action="default:show" />

   <url pathinfo="/articles/:rubrique/:id_art" module="cms" action="show">
      <param name="rubrique" type="string" />
      <param name="id_art" regexp="\d+" />
   </url>

<param name="type" regexp="(?:0|1|2){1}" />

   <url pathinfo="/:category/:product" module="shop" action="product:view">
      <param name="product"  regexp="\d{2}" />
      <static name="details" value="0" />
   </url>
   <url pathinfo="/:category/:product/details" module="shop" action="product:view">
      <param name="product"  regexp="\d{2}" />
      <static name="details" value="1" />
   </url>

   <url pathinfo="/articles/en/:page" module="cms" action="page:view">
      <param name="page"/>
      <static name="lang" value="en_EN" />
   </url>
   <url pathinfo="/articles/fr/:page" module="cms" action="page:view">
      <param name="page"/>
      <static name="lang" value="fr_FR" />
   </url>

Nous avons vu précédemment comment utiliser, en fin de compte, un système par défaut d'analyse et de génération d'URL avec ses pathinfos et paramètres. Il se peut que ce système ne soit pas suffisant. Imaginons par exemple que vous vouliez transformer une partie de l'information contenue dans le pathinfo, comme par exemple chercher dans une base de données un id correspondant à un titre contenu dans le pathinfo, et fournir ainsi aux actions, non pas un titre, mais un id (qui n'est pas contenu dans cette URL).

Ou encore que la partie pathinfo puisse être variable.

Aussi c'est à vous de développer l'analyse de l'URL et d'indiquer l'action à exécuter. Vous le ferez dans une classe spécialisée :

class myHandlerUrlsHandler implements jIUrlSignificantHandler {

    function parse($url){
        
        if(preg_match("/^\/(.*)$/",$url->pathInfo,$match)){
            $urlact = new jUrlAction($url->params);
            $urlact->setParam('page',jUrl::unescape($match[1]));
            return $urlact;
        }else
            return false;
    }

    function create($urlact, $url){

        $p=jUrl::escape($url->getParam('page'));

        $url->pathInfo = "/$p";
        $url->delParam('page');
    }
}

Le nom de la classe doit commencer par un préfixe que vous voulez et se terminer par UrlsHandler. La classe sera stockée dans le répertoire classes/ du module indiqué dans la balise url, sous le nom prefixe.urlhandler.php. Pour notre exemple :

  myHandler.urlhandler.php

La méthode parse() est chargée d'analyser une URL (objet jUrl que vous recevez en paramètre), en l'occurence, l'URL demandée dans l'application. Si votre handler reconnaît l'URL, parse() doit renvoyer un objet jUrlAction qui contient toutes les données pour l'action. Sinon il doit renvoyer false.

La méthode create() est appelée à chaque fois que l'application demande la création d'une URL à partir de paramètres d'action. Elle reçoit donc un objet de type jUrlAction, et un objet de type jUrl. $urlaction contient donc les paramètres de l'action. Ces paramètres ont déjà été inclus dans l'objet $url. Vous devez donc modifier $url de façon à produire l'URL correspondante à l'action demandée. Dans l'exemple, on récupère le paramètre page, que l'on incorpore dans le pathinfo. Et comme il est dans le pathinfo, on le supprime alors des paramètres.

Notez l'usage de jUrl::escape() et jUrl::unescape(), pour "nettoyer" les chaînes à inclure dans un pathinfo (accents enlevés par ex).

Enfin dans le fichier urls.xml, vous devez indiquer l'utilisation de ce handler :

   <classicentrypoint name="wiki">
       <url handler="myHandler" module="unittest" action="url4" />
    </classicentrypoint>

Vous pouvez bien sûr indiquer un handler d'un autre module. Exemple :

   <classicentrypoint name="wiki">
       <url handler="autremodule~myHandler" module="unittest" action="url4" />
    </classicentrypoint>

Imaginons que nous avons une URL de ce type : "/article/54-titre" et par défaut, cela affiche l'article 54 avec une action nommée view par exemple :

   <url pathinfo="/article/:id_art-:title" module="cms" action="view" />

On veut pouvoir, sans changer l'url, indiquer d'autres actions dans certains cas, avec un paramètre action :

• "/article/54-titre?action=edit"
• "/article/54-titre?action=delete"

Note : On pourrait faire aussi /article/54-titre/edit ou /article/54-titre/delete , avec donc plusieurs balises urls, ce qui nous éviterait ce qui suit. Mais ce n'est pas très pratique quand l'URL est appelée suite à un formulaire par exemple.

Pour indiquer les actions alternatives autorisées, on ajoute un attribut actionoverride, contenant la liste des actions séparées par un espace ou une virgule :

   <url pathinfo="/article/:id_art-:title" module="cms" action="view" actionoverride="edit,delete" />

Vous n'avez pas forcément envie d'indiquer une URL significative pour les actions d'un module particulier. Par contre vous avez créé un point d'entrée dédié à un module. Toutes ces actions passeront par ce point d'entrée. Vous avez juste alors à faire comme ceci :

    <classicentrypoint name="news">
        <url module="news" />
    </classicentrypoint>

Vous pouvez indiquer plusieurs modules de cette façon pour un même point d'entrée.

Pour certaines actions vous voulez que l'accès soit en mode sécurisé de http (SSL). Vous indiquez alors un attribut https sur les balises <url> en question avec la valeur true. Si cela concerne toutes les actions/URLs d'un point d'entrée, alors vous mettrez cet attribut sur la balise <entrypoint> correspondante.

Attention : pour le moment, Jelix ne vérifie pas lors de l'exécution d'une action que la requête a été faite en https ou non.

Depuis la version 1.2, il est possible de déclarer les urls dans chaque module, donc dans des fichiers séparés. Cela évite d'avoir un fichier urls.xml volumineux, mais surtout évite d'avoir à définir ou à "recopier" les urls d'un module réalisé par un tiers.

Pour ce faire, vous devez créer un fichier urls.xml dans le répertoire du module (vous pouvez choisir un autre nom que urls.xml). Ce fichier ne contient pas une balise racine urls mais suburls, et contient uniquement des balises url (pas entrypoint). Voici celui du module jauth comme exemple :

<?xml version="1.0" encoding="utf-8"?>
<suburls xmlns="http://jelix.org/ns/suburls/1.0">
    <url pathinfo="/dologin" action="login:in" />
    <url pathinfo="/dologout" action="login:out" />
    <url pathinfo="/login" action="login:form"/>
</suburls>

Et dans le fichier urls.xml principal, dans une des balises entrypoint, vous indiquez

  <entrypoint name="index">
    ...
     <url pathinfo="/auth" module="jauth" include="urls.xml" />
  </entrypoint>

Cela signifie : il faut inclure toutes les urls qui sont dans le fichier urls.xml du module jauth, et préfixer le pathinfo de ces urls par le chemin "/auth/". Autrement dit, l'url pour l'action "jauth~login:in" sera "/auth/dologin".

Cela signifie aussi que les urls que vous indiquez dans un fichier de module ne sont pas des urls complètes. Cela permet à l'utilisateur du module de choisir le chemin (en tout cas, le début du chemin) pour les urls du module, et éviter donc des doublons avec d'autres modules.

Dans un fichier URL de module, vous pouvez déclarer des urls avec un pathinfo complet, avec un pathinfo avec variables (formatées ou non), avec des paramètres statiques, avec un handler. Par contre, il est obligatoire de spécifier une url pour chaque action. Notez aussi qu'il ne faut pas utiliser l'attribut module, cela n'aurait pas de sens.

Bien sûr, vous devez faire un fichier d'urls pour chaque type d'action : un fichier pour le point d'entrée classique, un fichier pour chaque autre type de point d'entrée etc.

Vous préférez peut être que l'analyse des URLs se fasse par le serveur web, grâce au module rewrite pour apache par exemple. Vous allez donc écrire les règles de réécriture.

Réécriture complète par le serveur web ¶

 [urlengine]
  ..
  enableParser = off

Suppression du nom du point d'entrée dans l'URL ¶

 http://monsite.com/index.php/news/2007-02-08-il-neige-a-lille.html

 http://monsite.com/news/2007-02-08-il-neige-a-lille.html

 [urlengine]
  ..
  enableParser = on

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ index.php/$1 [L,QSA]
</IfModule>

    RewriteRule ^(.*)$ index.php?jpathinfo=/$1 [L,QSA]

[urlengine]
...
pathInfoInQueryParameter = jpathinfo