Exemples

Citation

2014-08-06 à 17:05:56 par Patrick Boens

Des îles qui s'activent en fonction du type de browser (2013-01-20)

Depuis l'opus "5.0.0012"

Il est aussi possible, depuis l'opus 5.0.0012, d'activer et désactiver des îles sur la base du type de browser. La classe LSBrowser, au travers de sa routine de parsing, permet de déterminer le type de navigateur du visiteur : browser ou bot (moteur de recherche, spider, crawler, …).

Il est déconseillé de présenter un contenu différent pour les moteurs de recherche (créer un contenu spécialisé, spécifiquement conçu pour les moteurs de recherche). Par contre, certains contenus n'ont aucun intérêt pour les moteurs de recherche comme par exemple des îles d'activation des réseaux sociaux, des îles de modification de la taille des polices, … C'est pour ces cas-là que nous introduisons le filtre browsertype sur l'activation des îles et des archipels. En voici un exemple :

<Island id="share" class="LSContentsShare" browsertype="!=bot">
    <param name="quitus"><![CDATA[false]]></param>
    <param name="facebook"><![CDATA[true]]></param>
    <param name="linkedin"><![CDATA[true]]></param>
    <param name="twitter"><![CDATA[true]]></param>
    <param name="digg"><![CDATA[true]]></param>
    <param name="delicious"><![CDATA[true]]></param>
    <param name="google"><![CDATA[true]]></param>
    <param name="stumbleupon"><![CDATA[true]]></param>
    <param name="wikio-fr"><![CDATA[true]]></param>
    <param name="reddit"><![CDATA[true]]></param>
    <param name="targets"><![CDATA[quitus;facebook;linkedin;twitter;digg;delicious;google;stumbleupon;wikiofr;reddit]]></param>
</Island>

La syntaxe permet l'utilisation de la négation : browsertype="!=bot" veut dire tous les types de browser sont permis sauf les types 'bot'. browsertype="browser" est la syntaxe positive (tous les browsers de type 'browser').

L'utilisation de filtres dans l'assignation des paramètres des îles n'est pas pris en compte pour le calcul des caches (cache sur île, cache sur archipel ou cache sur page). Soyez dès lors prudent dans l'application desdits filtres et des caches.

Le géorama possède des variables magiques (2013-01-19)

Depuis l'opus "5.0.0012"

Le géorama de la version 5.0.0012 possède maintenant quelques variables magiques, des variables prédéfinies dont vous pouvez vous servir à tous les endroits où les variables du géorama sont résolues.

Il vous est loisible de définir des variables "géorama" de la manière suivante :

<Georama>
  <Vars>
      <Var name="geo-path"><![CDATA[/../georama]]></Var>
      <Var name="islands"><![CDATA[/islands]]></Var>
      <Var name="quitus-root"><![CDATA[/q]]></Var>
      <Var name="editors"><![CDATA[admin;webmaster]]></Var>
  </Vars>
  …
</Georama>

Mais Vae Soli! définit aussi des variables qui lui sont propres et dont vous pouvez faire usage. À ce jour, le 19/01/2013 à 11:18, les variables définies automatiquement, appelées variables magiques du géorama, sont :

1. today(): aujourd'hui, dans le format 'YYYYMMDD'
2. now(): maintenant, dans le format 'YYYYMMDDHHmmSS'
3. day(): le jour de la semaine, en anglais ('monday' à 'sunday')
4. month(): le mois de l'année, en anglais ('january' à 'december')
5. year(): l'année dans le format 'YYYY'
6. utc(): maintenant, dans le format UTC (un nombre entier)
7. domain(): le domaine concerné (ex: 'www.vaesoli.poc')
8. topdomain(): le domaine global (ex: 'vaesoli')
9. mobility(): le type de mobilité (cfr. les données de LSBrowser; ex: desktop, phone, tablet, …)
10. browser(): le nom du browser (cfr. les données de LSBrowser; ex. Opera)
11. browser-type(): le type de browser (cfr. les données de LSBrowser; ex. browser, bot)
12. TRACING_NONE_LEVEL: 0
13. TRACING_ABOVE_NONE_LEVEL: 1
14. TRACING_ERROR_LEVEL: 16
15. TRACING_ABOVE_ERROR_LEVEL: 17
16. TRACING_QUESTION_LEVEL: 32
17. TRACING_WARNING_LEVEL: 48
18. TRACING_GOOD_TO_KNOW_LEVEL: 50
19. TRACING_INFO_LEVEL: 64
20. TRACING_INFO_MEDIUM_LEVEL: 128
21. TRACING_INFO_HIGH_LEVEL: 256
22. TRACING_INFO_HIGHHIGH_LEVEL: 512

Le géorama utilise désormais les variables qui y sont définies pour résoudre le paramétrage de logging et de tracing (2013-01-19)

Depuis l'opus "5.0.0012"

Vae Soli! définit les variables magiques (des pseudo fonctions en fait) today() domain() et topdomain(). Ces variables peuvent être utilisées pour spécifier le paramétrage de logging et de tracing comme le démontre l'exemple suivant :

<Settings>
    <LSTracingLevel><![CDATA[%TRACING_WARNING_LEVEL%]]></LSTracingLevel>
    <LSTracingOutput><![CDATA[/../logs/%topdomain()%.%today()%.log]]></LSTracingOutput>
    <LSTracingFilter><![CDATA[]]></LSTracingFilter>
</Settings>

L'exemple précédent spécifie un niveau de logging tel que défini dans le code source de Vae Soli! (LSTracingLevels.inc) … ce qui est le sens de %TRACING_WARNING_LEVEL%. Le fichier dans lequel le logging sera sauvé est variable (très utile dans le cas où le même site physique sert de multiples domaines … comme par exemple www.latosensu.org, www.latosensu.be, www.quitus.be, …, etc.). Pour le domaine global 'vaesoli' et la journée du '20210422' le fichier de logging sera donc égal à '/../logs/vaesoli.20210422.log'. On créera ainsi un fichier de log différent par jour.

Cette notation vous dédouane par exemple de créer des sections différentes par domaine traité. Voici, à titre d'information, la manière dont le fichier de logging/tracing est mentionné sur le site de Lato Sensu Management :

<LSTracingLevel><![CDATA[%TRACING_WARNING_LEVEL%]]></LSTracingLevel>
<LSTracingOutput><![CDATA[/../logs/%topdomain()%.%year()%.%month()%.%mobility()%.log]]></LSTracingOutput>

Comme vous pouvez le constater, Lato Sensu Management utilise une expression relativement complexe par laquelle le domaine global est pris en compte, le type de mobilité (desktop, phone ou tablet), le mois de l'année, et l'année. Le résultat est saisissant puisque de cette manière Lato Sensu Management est capable d'agréger les traces par type de mobilité (notamment les téléphones et les tablettes) et cela par mois (l'année est également prise en compte). Ce positionnement multiplie peut-être les fichiers de log, mais ils demeurent ainsi à des tailles raisonnables et permettent une analyse fine des types d'accès.

Le géorama se dote d'une nouvelle méthode : ListVariables() (2013-01-19)

Depuis l'opus "5.0.0012"

Par facilité, vous disposez à présent d'une méthode dans l'objet LSGeorama qui vous permet de connaître la liste des variables définies dans le géorama, celles que vous avez définies vous même et celles définies par Vae Soli!.

<?php
    $aVars = $this->oApp->oGeorama->ListVariables();
    var_dump( $aVars );
?>

… ce qui donne sur notre site (www.vaesoli.com)  :

D:\websites\vaesoli.org\www\httpdocs\islands\samples-body-contents_fr-17.php:232:
array (size=25)
  'today()' => string '20210422' (length=8)
  'now()' => string '20210422191437' (length=14)
  'day()' => string 'thursday' (length=8)
  'month()' => string 'april' (length=5)
  'year()' => string '2021' (length=4)
  'utc()' => string '1619111677' (length=10)
  'domain()' => string 'www.vaesoli.com' (length=15)
  'topdomain()' => string 'vaesoli' (length=7)
  'mobility()' => string 'desktop' (length=7)
  'browser()' => string 'CCBot' (length=5)
  'browser-type()' => string 'bot' (length=3)
  'TRACING_NONE_LEVEL' => int 0
  'TRACING_ABOVE_NONE_LEVEL' => int 1
  'TRACING_ERROR_LEVEL' => int 16
  'TRACING_ABOVE_ERROR_LEVEL' => int 17
  'TRACING_QUESTION_LEVEL' => int 32
  'TRACING_WARNING_LEVEL' => int 48
  'TRACING_GOOD_TO_KNOW_LEVEL' => int 50
  'TRACING_INFO_LEVEL' => int 64
  'TRACING_ENTRY_LEVEL' => int 64
  'TRACING_INFO_MEDIUM_LEVEL' => int 128
  'TRACING_INFO_HIGH_LEVEL' => int 256
  'TRACING_INFO_HIGHHIGH_LEVEL' => int 512
  'geo-path' => string '/../georama' (length=11)
  'iles' => string '/islands' (length=8)

Faites néanmoins attention à ne pas révéler quoi que ce soit de ce que vous estimez devoir rester caché (la sécurité avant tout !).

Comment avoir accès aux propriétés internes des îles dans le contenu de celles-ci (2013-01-11)

Depuis l'opus "5.0.0011"

Chaque île référencée dans les archipels composant une page donne lieu à la création d'un objet dont la classe est indiquée dans la définition XML de l'île. Par exemple, …

<Archipelago id="body" active="yes" category="Q-body">
    <Island id="pret-auto" active="yes" class="LSContents">
        <param name="storage">%islands%/{island->id}.php</param>
    </Island>
</Archipelago>

… donne lieu à la création d'un objet de classe LSContents dont le contenu sera extrait du fichier pret-auto.php ("{island->id}" étant substitué par l'ID de l'île, ici "pret-auto").

Pour autant, dans le contenu, pret-auto.php en l'occurrence, il n'est pas possible d'avoir accès aux propriétés de l'objet LSContents qui a été créé par Vae Soli! parce qu'il s'agit d'un objet interne. Pas possible avec les versions antérieures de la 5.0.0011 !

Tout change avec l'opus 5.0.0011 de Vae Soli! grâce à la propriété oActiveIsland de l'objet LSPage. Ainsi, voyez comment nous affichons l'ID de l'île courante dans le contenu qu'on lui demande d'afficher :

pret-auto.php
-------------
<?php
if ( $this instanceof LSPage )
{
    if ( $this->oActiveIsland instanceof LSIsland )
    {
        echo "<p>Bonjour {$this->oUser->szFirstname} {$this->oUser->szLastname},</p>\n";
        echo "<p>Mon l'île s'appelle '" . $this->oActiveIsland->id . "'</p>";
    }
}
?>

$this, dans un contenu, se réfère à l'objet Page qui a été créé (LSPage). Avec le $this vous avez donc accès à oActiveIsland, la porte d'entrée de toutes les propriétés de l'île. CQFD.

Il y a aussi un petit plus : la liste de toutes les îles incluses! Il s'agit ni plus ni moins d'une collection d'îles accessibles via le tableau aIslands de l'objet LSPage. Cette collection d'îles est construite au fur et à mesure ce qui veut donc dire que la première île n'a pas connaissance de la deuxième mais la deuxième connaît la première (chaque île précédente ignore la suivante mais la suivante connaît la précédente). Voici un exemple qui démontre l'affaire :

<?php
if ( $this instanceof LSPage )
{
    var_dump( $this->aIslands );
}
?>

… et comme oActiveIsland est un objet de classe LSIsland …

Vous pouvez dès lors accéder à n'importe quelle méthode de cet objet, à n'importe quelle propriété … comme par exemple la propriété oNode (de type DOMElement). oNode vous permet donc d'avoir accès aux attributs du noeud d'origine de l'île, comme mentionné dans votre géorama.

Vae Soli! 5.0.0010 : le fichier halt.sem (2012-11-29)

Depuis l'opus "5.0.0010"

Grâce au fichier halt.sem, vous pouvez contrôler le START / STOP de votre serveur web … enfin plutôt de Vae Soli! … qui refusera de traiter les pages demandées par le visiteur. Voyons comment…

Le Start et Stop du serveur se contrôlent par la présence (ou l'absence) du fichier halt.sem^[1] dans la racine du site. Si ce fichier est présent, le site est arrêté (sauf quelques pages qui continuent à être servies, dont la page qui contient le Site Manager, pour des raisons évidentes). Si ce fichier est absent, le site fonctionne tout naturellement ce qui veut donc dire que Vae Soli! traite les requêtes comme si de rien n'était.

Le fichier halt.sem doit contenir l'adresse vers laquelle il faut brancher l'exécution du site (l'URL de substitution). Quatre cas distincts ont été programmés jusqu'à présent dans la classe LSSiteManager :

1. L'arrêt du site (ou sa non disponibilité) pour cause de CONSTRUCTION
2. L'arrêt du site (ou sa non disponibilité) pour cause de MAINTENANCE
3. L'arrêt du site (ou sa non disponibilité) pour cause AUTRE
4. La redirection pure et simple du site vers un AUTRE SITE

Voici un capture d'écran qui illustre la partie START / STOP du Site Manager :

Vae Soli! 5.0.0010, les îles et les cookies (2012-11-02)

Depuis l'opus "5.0.0010"

Avec la version 5.0.0010 de Vae Soli!, chaque île peut désormais facilement positionner des cookies. Voici comment :

<Island id="booking" active="yes" class="LSContentsBooking" memberof="booking;quitus;admin">
    <role-mapping role="admin" groups="admin" />
    <param name="cookie" cookie-name="{island->id}-last-visit" cookie-ttl="2592000">{today()}</param>
    <param name="storage"               ><![CDATA[/court-booking/bookings.xml]]></param>
    <param name="resource-file"         ><![CDATA[/court-booking/courts.xml]]></param>

    <param name="title"                 ><![CDATA[Court Booking]]></param>

    <param name="CSSClass"              ><![CDATA[booking]]></param>

    <param name="with-quantity"         >false</param>
    <param name="with-attendance"       >false</param>
    <param name="with-terms"            >true</param>
    <param name="with-remember-me"      >true</param>

    <param name="show-calendar"         >true</param>
    <param name="show-form">true</param>
    <!-- <param name="show-form" port="8000"><![CDATA[.php= return IsRelation( 'mem' );]]></param> -->
    <param name="show-form"             >false</param>
    <param name="show-admin"            >true</param>

    <param name="calendar-title"        lang="nl"><![CDATA[Reserverings]]></param>
    <param name="calendar-title"        lang="en"><![CDATA[Reservations]]></param>
    <param name="calendar-title"        ><![CDATA[Réservations]]></param>
    <param name="calendar-day-format"   device="iphone"><![CDATA[short]]></param>
    <param name="calendar-date-format"  device="iphone"><![CDATA[d-m]]></param>
    <param name="calendar-day-format"   device="samsung" model="galaxy s ii"><![CDATA[short]]></param>
    <param name="calendar-date-format"  device="samsung" model="galaxy s ii"><![CDATA[d-m]]></param>
    <param name="multiselect"           member="admin">true</param>
    <param name="multiselect"           >false</param>
    <param name="mandatory-mark"        ><![CDATA[ (*)]]></param>
    <param name="resource-type"         ><![CDATA[court]]></param>

    <param name="start-hour"            >11</param>
    <param name="end-hour"              >22</param>
    <param name="minutes-per-slot"      >30</param>
    <param name="cut-off"               ><![CDATA[-1/16:00]]></param>
    <param name="cut-off"               >86400</param>
    <param name="timezone"              ><![CDATA[Europe/Brussels]]></param>

    <param name="date-from-to"          >false</param>

    <param name="debug"                 ip="127.0.0.1">true</param>

    <param name="foreword-label"        ><![CDATA[{booking-foreword}]]></param>
    <param name="resource-label"        ><![CDATA[{resource}]]></param>
    <param name="resource-tooltip"      ><![CDATA[{resource-tooltip}]]></param>
    <param name="attendance-label"      ><![CDATA[{attendance}]]></param>
    <param name="attendance-tooltip"    ><![CDATA[{attendance-tooltip}]]></param>
    <param name="zipcity-label"         ><![CDATA[{zip-and-city}]]></param>
    <param name="objective-label"       ><![CDATA[{objective}]]></param>
    <param name="objective-tooltip"     ><![CDATA[{objective-tooltip}]]></param>

    <param name="can-edit"              >true</param>
    <param name="can-delete"            >true</param>
    <param name="edit-icon"             ><![CDATA[{booking-edit-icon}]]></param>
    <param name="delete-icon"           ><![CDATA[{booking-delete-icon}]]></param>
    <param name="confirm-delete"        ><![CDATA[{confirm-delete}]]></param>

    <param name="form-title"            ><![CDATA[{form-title}]]></param>
    <param name="date-filling"          ><![CDATA[next week]]></param>
    <param name="form-version"          ><![CDATA[web 2.0]]></param>

    <param name="data-saved-msg"        ><![CDATA[{data-saved}]]></param>
    <param name="data-not-saved-msg"    ><![CDATA[{data-not-saved}]]></param>
    <param name="data-not-validated-msg"><![CDATA[{data-not-validated}]]></param>

    <param name="close-button-alt"      ><![CDATA[{close-button-alt}]]></param>
    <param name="close-button-title"    ><![CDATA[{close-button-title}]]></param>

    <param name="publish-names"         >true</param>

</Island>

L'exemple ci-dessus démontre le principe des cookies sur îles au départ d'une île a priori compliquée, l'île de réservation de ressources. Mais comme vous le constatez, le positionnement d'un cookie est relativement simple puisqu'une seule ligne suffit.

Les propriétés sont résolues (ex. {island->id} qui sera transformé en booking); les variables du géorama sont résolues; les substitutions sont également résolues (ex. {today()} qui sera transformé en ce que la substitution aura défini, par exemple 02/11/2012).

Vous pouvez positionner autant de cookie que vous voulez.

Contenus alternatifs (2012-10-29)

Depuis l'opus "5.0.0010"

La définition de fichiers de contenus alternatifs correspond à ceci : si le contenu par défaut n'est pas disponible, alors on voudrait un contenu alternatif. Si le contenu alternatif n'est pas disponible, alors on voudrait un autre contenu alternatif. Une stratégie de fallback en quelque sorte.

L'opus 5.0.0100 prévoit donc cette nouvelle fonctionnalité de contenus alternatifs sous la forme :

<Island id="silos" active="yes" class="LSContents">
    <param name="storage"><![CDATA[%islands%/{archipelago->id}-{page->lang}.php]]></param>
    <param name="alt-storage"><![CDATA[%islands%/{archipelago->id}-{page->lang}.php]]></param>
    <param name="alt-storage"><![CDATA[%islands%/{archipelago->id}.php]]></param>
</Island>

… ce qui doit se lire comme suit : si le contenu %islands%/{archipelago->id}-{page->lang}.php n'est pas disponible, alors essayer d'inclure le contenu %islands%/{archipelago->id}-{page->lang}.php; si ce deuxième contenu n'est toujours pas disponible, alors essayer le contenu %islands%/{archipelago->id}.php]]></param>, etc. Vous pouvez définir AUTANT de contenus alternatifs que vous souhaitez, allant ainsi du plus particulier au plus général.

Filtrer les îles sur base de la page courante : land (2012-10-05)

Depuis l'opus "5.0.0007"

Il se pourrait que vous souhaitiez faire en sorte qu'une île ne soit rendue que sur une page bien particulière. Vous nous direz qu'il vous est facile de faire la chose en n'incluant l'île en question QUE dans la définition de CETTE page. Certes, vous avez raison. Mais qu'en est-il par exemple de ces îles que vous avez mentionnées dans des classes géorama ? Puisque ce sont des classes, et que la définition d'une page peut hériter de la classe en question, l'île est donc incluse dans TOUTES les pages qui se réclament de cette classe et l'île sera donc rendue. Vrai, sauf si …

Sauf si vous vous servez du nouveau filtre, land. Voyez l'exemple suivant :

<Archipelago id="menu" active="yes" category="menu">
    <Island id="menu" active="yes" class="LSContents" land="/index.php">
        <param name="storage"><![CDATA[/template/main-menu-{page->lang}.php]]></param>
    </Island>
</Archipelago>

Finalement, cette île ne sera rendue QUE sur la page /index.php. Vous pouvez vous servir de ',' ou ';' pour mentionner d'autres pages pour lesquelles l'île doit être rendue. Fabuleux mais …

Il y a effectivement un MAIS et il est de taille. Souvent ce qu'on voudrait c'est plutôt mentionner les pages où l'île ne doit PAS être rendue (plutôt que de donner la liste des pages où elle doit être rendue). Bonne nouvelle ! Vae Soli! accepte les deux syntaxes mais vous devrez choisir entre l'une et l'autre : la négation est testée par le caractère !.

<Archipelago id="menu" active="yes" category="menu">
    <Island id="menu" active="yes" class="LSContents" land="!/q/index.php">
        <param name="storage"><![CDATA[/template/main-menu-{page->lang}.php]]></param>
    </Island>
</Archipelago>

L'utilisation de filtres dans l'assignation des paramètres des îles n'est pas pris en compte pour le calcul des caches (cache sur île, cache sur archipel ou cache sur page). Soyez dès lors prudent dans l'application desdits filtres et des caches.

Filtre mobility sur l'extraction des paramètres des îles (2012-09-30)

Depuis l'opus "5.0.0007"

Une clause de filtrage supplémentaire est apparue dans l'extraction des paramètres d'une île, la clause mobility. Cette clause s'appuye sur la classe LSBrowser laquelle permet de détecter le type d'appareil auquel on a affaire suivant le User Agent. Une des valeurs retournées par la classe est justement le caratère mobile de l'appareil (ou pas) : desktop, mobile ou tablet. Nous pouvons dès lors nous servir de cette valeur pour filtrer les paramètres des îles.

Par exemple, imaginons que nous souhaitions réduire la complexité du formulaire de contact, île de type LSContentsContactForm, en n'obligeant pas l'internaute à remplir certaines données s'il opère au départ d'un téléphone…

<Island id="contact-form"       active="yes" class="LSContentsContactForm">
    <param name="submit"        ><![CDATA[self]]></param>
    <param name="company"       mobility="mobile"><![CDATA[false]]></param>
    <param name="company"       ><![CDATA[true]]></param>
    <param name="firstname"     ><![CDATA[true]]></param>
    <param name="birthdate"     mobility="mobile"><![CDATA[false]]></param>
    <param name="birthdate"     ><![CDATA[true]]></param>
    <param name="address"       mobility="mobile"><![CDATA[false]]></param>
    <param name="address"       ><![CDATA[true]]></param>
    <param name="phone"         mobility="mobile"><![CDATA[false]]></param>
    <param name="phone"         ><![CDATA[true]]></param>
    <param name="homepage"      mobility="mobile"><![CDATA[false]]></param>
    <param name="homepage"      ><![CDATA[false]]></param>
    <param name="body"          ><![CDATA[true]]></param>
</Island>

Grâce à cette clause, on peut donc simplifier les formulaires en appliquant des paramètres différents en fonction de la mobilité (propriété détectée par le parsing du User Agent), et ce n'est là qu'un des multiples exemples de l'application de cette nouvelle clause.

L'utilisation de filtres dans l'assignation des paramètres des îles n'est pas pris en compte pour le calcul des caches (cache sur île, cache sur archipel ou cache sur page). Soyez dès lors prudent dans l'application desdits filtres et des caches.

Paramètres à valeur variable grâce au filtre land (2013-01-17)

Depuis l'opus "5.0.0012"

Vous avez vu que le filtre mobility pouvait être appliqué à l'extraction de la valeur d'un paramètre. Vous disposez du même mécanisme avec le filtre land. Nous vous renvoyons à la même explication fournie pour une île. En voici une application basique :

<Island id="coordinates" active="yes" class="LSContentsBusinessCoordinates">
    <param name="business-name" land="/contact.php"><![CDATA[Société Tartempion]]></param>
    <param name="business-name" land="/devis.php"><![CDATA[Société JohnDoe]]></param>
    <...>
</Island>

L'utilisation de filtres dans l'assignation des paramètres des îles n'est pas pris en compte pour le calcul des caches (cache sur île, cache sur archipel ou cache sur page). Soyez dès lors prudent dans l'application desdits filtres et des caches.

Le fichier vaesoli.php est chargé automatiquement (2012-09-17)

Depuis l'opus "5.0.0006"

Si un script vaesoli.php (attention à la casse) est trouvé dans le même répertoire que le script PHP en train de s'exécuter, Vae Soli! le charge automatiquement. C'est un peu un comportement similaire à ce que ColdFusion propose avec le application.cfm.

Expressions PHP sur les href (2012-09-17)

Depuis l'opus "5.0.0006"

Une fonctionnalité mineure qui peut mener à des avancées majeures. Voilà comment nous qualiferions la possibilité de bénéficier d'expressions PHP sur la définition d'îles. Voici un exemple de définition de page faisant usage de href :

<Land id="/articles/index.php"
      inherit="articles"
      href="%geo-path%/articles.pdef.xml">
    <Sitemap priority="0.6" frequency="weekly" />
</Land>

Il s'agit ici de ne plus avoir une définition fixe comme href="%geo-path%/articles.pdef.xml" mais d'avoir plutôt une expression totalement variable comme href=".php= return GiveMeAPageDef();", la fonction GiveMeAPageDef() se chargeant alors de renseigner le bon fichier où se trouve la définition de la page. On en déduit bien entendu le côté hautement dynamique des définitions possibles (et partant la simplification formidable dont pourrait jouir n'importe quel géorama).

<Land id="/articles/index.php"
      inherit="articles"
      href=".php= return GiveMeAPageDef();">
    <Sitemap priority="0.6" frequency="weekly" />
</Land>

Attention cependant … la définition de la fonction GiveMeAPageDef() DOIT être connue de votre code. Sachez en particulier que les procédures chargées par <LSSetProceduresTo>…</LSSetProceduresTo> le sont APRÈS l'invocation de la fonction GiveMeAPageDef(). Chargez donc votre code AVANT, par exemple en le mettant dans le fichier vaesoli.php qui est chargé automatiquement avec la version 5.0.0007 de Vae Soli!.

Vae Soli! et expirations de page (2012-09-14)

Depuis l'opus "5.0.0006"

C'est un feature à utiliser avec précaution; c'est un feature aussi extrêmement puissant : la gestion de l'expiration d'une page.

Lorsque vous avez des pages qui peuvent carrément être considérées comme statiques, vous pouvez en améliorer de manière inimaginable la performance en spécifiant que ladite page peut être complètement mise en cache par le navigateur du visiteur pour un certain temps (qu'il vous appartient de déterminer). Dans ce cas, tout appel à la page sera ENTIÈREMENT résolu par le cache du navigateur.

Au rang des avantages de cette technique on trouve bien évidemment en premier lieu le sentiment d'aisance éprouvé par le visiteur : la page est montrée instantanément (époustouflant sur un smartphone par exemple).

Mais ce n'est évidemment pas le seul avantage de cette technique : vous libérez singulièrement le serveur de tout appel puisque la requête invoquée par le navigateur se fait en local plutôt que d'aller jusqu'à votre serveur web. C'est de la bande passante que vous gagnez pour les appels qui se justifient vraiment ! Ce n'est pas rien !

Il n'existe pas d'inconvénient connu à la technique pourvu qu'on garde en tête le fait que le contenu n'est évidemment pas rafraîchi. Il faut donc éviter d'activer cette fonctionnalité sur des pages qui comportent des contenus hautement dynamiques (sauf à utiliser des techniques actives sur l'environnement du visiteur - Ajax, par exemple) comme des pages avec des offres client variables, des contenus articulés par un contexte de session, etc.

La paramétrisation d'expiration est similaire (mais pas identique) à celle d'Apache. En voici un exemple issu de la paramétrisation d'une page dans le géorama :

<Defaults>
    <Settings>
        <!-- Overwrites the default settings of a page -->
        <LSGuid><![CDATA[3509fab5-df41-4443-93d1-362fc9c33313]]></LSGuid>
        <LSLinkDefs><![CDATA[/template/links_sultan]]></LSLinkDefs>
        <LSKeyword><![CDATA[homepage]]></LSKeyword>
        <LSIsBlog><![CDATA[false]]></LSIsBlog>
        <LSExpirationHeader><![CDATA[next month]]></LSExpirationHeader>
    </Settings>
</Defaults>

Voici la liste des syntaxes possibles :

• next year | [access [plus]] <x> year[s]
• next month | [access [plus]] <x> month[s]
• next week | [access [plus]] <x> week[s]
• next day | [access [plus]] <x> day[s]
• next hour | [access [plus]] <x> hour[s]
• next minute | [access [plus]] <x> minute[s]
• next second | [access [plus]] <x> second[s]

Exemples de syntaxes

<LSExpirationHeader><![CDATA[next month]]></LSExpirationHeader>
<LSExpirationHeader><![CDATA[next day]]></LSExpirationHeader>
<LSExpirationHeader><![CDATA[access plus 2 years]]></LSExpirationHeader>
<LSExpirationHeader><![CDATA[access 129600 seconds]]></LSExpirationHeader>
<LSExpirationHeader><![CDATA[access 5 weeks]]></LSExpirationHeader>
<LSExpirationHeader><![CDATA[access plus 5 weeks]]></LSExpirationHeader>
<LSExpirationHeader><![CDATA[next hour]]></LSExpirationHeader>

Vae Soli! et le filtre de visite (2012-09-14)

Depuis l'opus "5.0.0007"

Vae Soli! permet de filtrer les contenus sur base de la visite courante de l'utilisateur. Ce feature permet de ne présenter un certain contenu, une île par exemple, que si l'utilisateur est passé par certaines pages, lesquelles font justement l'objet du filtre. On pense bien évidemment à ces pages où certains contenus peuvent varier en fonction de la visite de l'internaute, des contenus de promotions ou d'offres par exemple.

Par exemple, la présente page propose une île de contenu (type xhtml) QUE SI vous êtes passés par la page help. Dans ce cas le message suivant sera affiché: "Vous êtes passés par la page help. Merci de votre visite". Voici la définition de cette île :

<Island id="my-island" xhtml="yes" trip="/help.php">
    <div style="border:3px solid silver;margin:15px auto;padding:10px;font-size:1.5em;font-weight:bold;">
        <p>Vous êtes passé par la page help. Merci de votre visite.</p>
    </div>
</Island>

L'utilisation de filtres dans l'assignation des paramètres des îles n'est pas pris en compte pour le calcul des caches (cache sur île, cache sur archipel ou cache sur page). Soyez dès lors prudent dans l'application desdits filtres et des caches.

Notes de bas de page

^[1] … L'extension sem veut dire semaphore

Précédent Suivant