Certains des exemples que nous fournissons ci-dessous ne sont pas complets. D'emblée, nous nous en excusons, bien sûr. Mais pourquoi diable sont-ils incomplets ?
Ils sont incomplets parce que nous y travaillons en ce moment et que plutôt que de vous faire patienter jusqu'à ce qu'ils soient tous terminés, nous avons préféré vous les livrer dans l'état où ils se trouvent pour que vous puissiez vous faire une idée de ce qu'ils illustrent.
Au fur et à mesure de notre avancement, nous ferons les mises à jour idoines. Nous espérons résorber notre retard au plus vite.
title
, le paramètre heading
, le paramètre text
, le paramètre xsl
, LSRegionSubtag, Language Switchers, LSFormEnroll, LSContentsLegal, sitemap, substitution de propriétés, LSSourceFile et LSContentsSourceFile, LSContentsComments, LSContentsCharter, ... (05/11/2013)onload
et onunload
d'une page, Page settings, ... (22/09/2013)Depuis l'opus "5.1.0000"
Ce filtre implique une authentification de l'utilisateur et aussi que son rating soit stocké dans son profil. Si ces deux conditions ne sont pas rencontrées, l'île (ou la page ou encore l'archipel) ne se montrera pas.
<Island id="services" active="yes" class="LSContents" user-rating="A,B"> <param name="storage"><![CDATA[/services.php]]></param> </Island>
L'exemple ci-dessus suggère que l'île ne se sera activée que si le rating
octroyé au visiteur soit A
ou B
. Le rating est
issu de la propriété szRating
de l'objet LSUser
.
Depuis l'opus "5.1.0000"
Ce filtre implique une authentification de l'utilisateur et aussi que sa date de naissance soit stockée dans son profil. Si ces deux conditions ne sont pas rencontrées, l'île (ou la page ou encore l'archipel) ne se montrera pas.
<Island id="services" active="yes" class="LSContents" user-birthdate="19591118"> <param name="storage"><![CDATA[/services.php]]></param> </Island>
L'exemple ci-dessus suggère que l'île ne se sera activée que si la date de naissance du visiteur est le 18 nov 1959. En soi, cela ne semble pas très utile … du moins si c'était là le seul format disponible, mais heureusement Vae Soli! propose une variété de formats :
YYYYMMDD
= Année - Mois - Jour (ex: 19591118
)YYYY-MM
= Année - Mois (ex: 1959-11
)MM-DD
= Mois - Jour (ex: 11-18
)dDD
= Jour (ex: d18
)mMM
= Mois (ex: m11
)yYYYY
= Année (ex: y1959
)a[[+-]=]999
= Âge (ex: a53
ou a+53
ou a+=53
ou a-53
ou a-=53
)
Avec autant de formats différents, on peut anticiper tous les types de cas
où la date de naissance du visiteur peut jouer le rôle de filtre de contenu.
Vous avez ainsi la possibilité de souhaiter un bon anniversaire à qqn
avec le format MM-DD
, la possibilité de présenter un contenu
pour les visiteurs âgés d'au moins 18 ans (a+=18
), etc.
Depuis l'opus "5.1.0000"
Ce filtre implique une authentification de l'utilisateur et aussi que son pays d'appartenance soit stocké dans son profil. Si ces deux conditions ne sont pas rencontrées, l'île (ou la page ou encore l'archipel) ne se montrera pas.
<Island id="services" active="yes" class="LSContents" user-country="FR;BE;UK"> <param name="storage"><![CDATA[/services.php]]></param> </Island>
L'exemple ci-dessus suggère que l'île ne se sera activée que si le pays d'appartenance du visiteur est la France, la Belqique ou le Royaume-Uni.
Depuis l'opus "5.1.0000"
Nous avons commencé à mettre à profit la classe LSAnalytics
développée l'an dernier pour effectuer l'analyse de pages web (voir à ce
propos la nouvelle du
17 juin 2012 sur le site de Lato Sensu Management).
Les routines développées dans ce cadre sont aujourd'hui à l'essai dans la qualification des pages. Qu'entendons-nous par qualification ? Il s'agit de la capacité de Vae Soli! à catégoriser les pages de manière automatique par le biais de la sélection de mots-clés structurants (c'est-à-dire des mots-clés qui représentent le mieux la page en question). Les mots-clés sont extraits automatiquement du contenu de la page. Cette extraction est dynamique et elle respecte l'aspect mobility (c'est-à-dire le type d'appareil qui a été demandé pour afficher la page — essentiellement les modes desktop, tablet, phone ou plus généralement mobile et la langue de la page. Le mode mobility est important pour la simple raison que le contenu d'une page peut varier en fonction du périphérique sur lequel elle est demandée (même si, au demeurant, cela ne devrait pas changer le sujet principal de la page).
Il est à noter que la qualification de page est une
fonctionnalité expérimentale de Vae Soli! 5.1.0000
et
qu'elle fera l'objet d'une publication officielle dès l'instant où nous la
considérerons comme stable et durable. C'est un travail important pour
Lato Sensu Management car il au au cœur d'une série de fonctionnalités capitale de
Quitus, la future gestion d'entreprise de Lato Sensu Management.
Voici l'exemple d'une page dont les mots-clefs sont extraits par Vae Soli! :
<Description title="Références" h1="Références" lang="fr"> <ExtendedDesc><![CDATA[Les références de Lato Sensu Management]]></ExtendedDesc> <Keywords qualify="yes"><![CDATA[portfolio, références,clients]]></Keywords> </Description>
Dès ce moment, la page est qualifiée chaque jour (du moins au moment où nous écrivons ces lignes).
Lorsque la qualification de page est activée, Vae Soli! génère un fichier de
mots-clés pour la page en question. L'aspect mobility[1] est
pris en compte de même que la langue dans laquelle la page est demandée. Si
la mobility est desktop
, que le script de la page est
/hello.php
et que la langue de la page est fr
,
alors Vae Soli! créera le fichier suivant :
/hello.php.desktop.fr.keywords
.
La connexion avec le module de recherche (module à venir) sera entièrement basée sur la qualification des pages. Au travers de la qualification d'une page nous disposerons aussi de tous les moyens nécessaires pour pouvoir effectuer des recherches avec indice de relevance. C'est un pan du travail qui reste à construire entièrement. Là également il s'agit d'une fonctionnalité structurante nécessaire à Quitus.
Depuis l'opus "5.1.0000"
La version 5.1.0000
aura des îles qui pourront être de type
placeholder
et d'autres qui pourront être de type
replace
.
Les îles de type placeholder
ne font que prévoir un
contenu futur qui ne peut pas être établi de manière définitive au moment où
elles doivent être insérées dans le flux de la page qui les
compose. Ce sera le rôle des îles replace
de remplacer
le contenu d'une île de type placeholder
.
Un exemple pratique vous expliquera mieux ce dont il s'agit. Imaginez en fait que vous souhaitiez placer une bannière d'information (ou de publicité) dans une page. Imaginez encore que ladite bannière soit dynamique : si la page parle de vêtements (elle possède un mot-clé comme "sportwear"), vous voulez afficher une bannière pour les dernières chaussures de sport qui vous restent en stock tandis que si la page parle de montres (elle possède un mot-clé comme "watches") vous souhaitez afficher une bannière pour la dernière montre-bracelet HUER. Imagnez encore que cette bannière soit à afficher en haut de la page (et donc assez en amont de la définition des îles qui composent la page). Vous pourriez alors être dans le cas suivant :
001 ... <Land xmlns:xi="http://www.w3.org/2001/XInclude" 002 ... xmlns:html="http://www.w3.org/1999/xhtml"> 003 ... <Description title="Sport Wear" h1="Sport Wear" lang="fr"> 004 ... <ExtendedDesc><![CDATA[Vêtements de sport et différents articles de sport]]></ExtendedDesc> 005 ... <Keywords><![CDATA[sportwear]]></Keywords> 006 ... </Description> 007 ... 008 ... <Defaults> 009 ... <Settings> 010 ... <LSGuid><![CDATA[MYSITE-04395b74-0147-4f18-9c29-3e372e86b748]]></LSGuid> 011 ... </Settings> 012 ... </Defaults> 013 ... 014 ... <Contents id="contents" class="rigolo"> 015 ... ... many archipelagos before 016 ... <Archipelago id="body" active="yes" category="body"> 017 ... <Island id="advert-banner" guid="advert-banner" placeholder="yes" /> 018 ... ... many additional islands 019 ... <Island id="advert-1" active="yes" class="LSContents" 020 replace="advert-banner" keywords="sportwear"> 021 ... <param name="storage"><![CDATA[sportwear-fr.html]]></param> 022 ... </Island> 023 ... <Island id="advert-2" active="yes" class="LSContents" 024 replace="advert-banner" keywords="watches"> 025 ... <param name="storage"><![CDATA[watches-fr.html]]></param> 026 ... </Island> 027 ... ... still additional islands 028 ... </Archipelago> 029 ... ... many additional archipelagos 030 ... </Contents> 031 ... </Land>
Dans l'exemple ci-dessus, l'île dont le guid est advert-banner
est une île de type placeholder
. Son contenu, au moment où
Vae Soli! est suscité pour le créer, ne peut pas encore être défini. Cette
île est en ligne 017.
En ligne 018 … on imagine de nombreuses autres îles. Des lignes 019
à 022 on définit une île de type replace
qui vient en
remplacement de l'île advert-banner
(celle définie en ligne
017). Cette île, au vu de son filtre keywords
ne s'affichera
QUE SI le mot-clé défini pour cette île est détecté dans les mots-clés de la
page (définis à la ligne 005). Ici le mot à considéré pour l'île
advert-1
est sportwear
.
Des lignes 023 à 026 on définit l'île advert-2
qui elle ne sera
affichée QUE SI le mot-clé qu'on lui a associé est watches
(en
ligne 024).
A priori, tel quel, c'est l'île advert-1
qui sera affichée et
celle-ci viendra prendre la place de l'île advert-banner
.
Comme vous le constatez, le mécanisme est limpide. Vous pourriez toutefois
vous poser la question de savoir en quoi il peut être rendu dynamique.
Comment faire varier les mots-clés de la page. En fait c'est très
simple ! On sait que quand le contenu d'une île est affiché, la source
mentionnée dans son storage
peut modifier les propriétés de la
page dans laquelle l'île est insérée. Une simple variation des mots-clés de
la page ($this->szKeywords
) permet d'obtenir une allocation
dynamique. Il n'est donc pas exclu que les mots-clés associés à une page
puissent non plus être définis statiquement, mais qu'ils le seraient de
manière dynamique … et dès lors donner lieu à l'affichage de
bannières intelligentes.
Depuis l'opus "5.0.0012"
Un message de service est un paramètre de l'URL chargé d'un sens défini et
qui influence le contenu qui sera renvoyé pour l'URL en question. Ainsi, si
par exemple vous utilisez le message de service {ua:…}
le contenu qui sera renvoyé par Vae Soli! correspondra à celui qui aurait
été renvoyé si le User Agent était effectivement celui
mentionné (avec les styles adaptés à l'UA en question).
Techniquement, Vae Soli! traite les messages de service via deux catégories distinctes :
Par exemple, si on demande l'exécution du message de service
{user:object}
(accessible uniquement en tant qu'administrateur
du site), il est inutile que Vae Soli! se lance dans la construction de
toute la page car ce qui est demandé par le message c'est de retourner une
vue de l'objet User courant. Voilà typiquement un message de
service avec construction de page interrompue.
Par contre, le message de service {ua:…}
implique quant à
lui que la construction de la page se poursuive : le message de service
ne faisant qu'influencer la construction mais ne l'interrompant pas.
Certains messages de service requièrent le mode authentifié. Ceci s'applique surtout pour les messages de service qui ne peuvent être traités que si l'utilisateur / visiteur fait partie du groupe admin.
Par exemple, il est possible d'invoquer le message de service
{dir:…}
par le biais duquel on demande le listing du
répertoire identifié par …
. Inutile de préciser que
seuls les administrateurs d'un site peuvent invoquer ce message de service.
Voilà qui requiert donc un mode authenticated
.
resume
Certains messages de service requièrent un traitement en deux étapes :
La seconde étape justifie le mode resume
du message de service.
À vrai dire, ce mode se justifie lorsqu'en étape #1, on ne dispose pas
encore de toutes les informations nécessaires pour mener le traitement du
message de service jusqu'à son terme.
Par exemple, le message de service {ua:…}
peut être
entièrement traité avec une seule étape : au moment où le message de
service est reçu on positionne la nature du User Agent et
la page est construite sur base de cette valeur. Simple et efficace.
Par contre, lorsqu'on invoque le message de service {body}
, on
commence par reconnaître le message de service, on laisse la page se
construire entièrement et ensuite, en mode resume
, on extrait
la balise <body>…</body>
et c'est le
contenu de cette balise qui sera renvoyé. C'est donc bel et bien un
traitement en deux étapes.
Vous pouvez contrôler l'utilisation des messages de service. Cela se
configure dans le fichier XML du géorama, ou à défaut, par un fichier
d'inclusion, généralement georama.xml
ou defaults.xml
.
<Defaults> <LSDoctype><![CDATA[html5]]></LSDoctype> <LSTracingLevel><![CDATA[SAME]]></LSTracingLevel> <LSTracingOutput><![CDATA[SAME]]></LSTracingOutput> <LSTracingFilter><![CDATA[SAME]]></LSTracingFilter> <LSPerfThreshold><![CDATA[0.050]]></LSPerfThreshold> <LSTemplate><![CDATA[/template/vaesoli.html]]></LSTemplate> <LSTheme><![CDATA[hello]]></LSTheme> <LSSubstitutions><![CDATA[%geo-path%/substitutions.xml]]></LSSubstitutions> <LSSubstitutionsCacheTTL><![CDATA[86400]]></LSSubstitutionsCacheTTL> <LSIsDebug><![CDATA[true]]></LSIsDebug> <LSMustWriteSourceHeader><![CDATA[false]]></LSMustWriteSourceHeader> <LSServiceMessages><![CDATA[true]]></LSServiceMessages> </Defaults>
Depuis l'opus "5.0.0012"
L'opus 5.0.0012
de Vae Soli! fournit une nouvelle petite arme à
ajouter à votre arsenal de programmeur : le Who Am
I?, littéralement Qui suis-je?. Cette petite fonctionnalité,
lorsqu'elle est utilisée dans le commentaire d'une île, est très utile pour
savoir de quel fichier de définition de page est extrait la composition de
l'île en question. Vous ne comprenez pas ? Soit ! Un petit
exemple vous indiquera de quoi il s'agit.
Imaginons qu'une page soit définie de la manière suivante dans le géorama :
<Land id="/toolkit/index.php" group="{main}" creationdate="20130129" lupdate="auto" inherit="public" href="%geo-path%/toolkit-{land->id}.pdef.xml"> <Sitemap priority="0.6" frequency="monthly" /> </Land>
On remarque immédiatement que la définition détaillée de la page se
trouve dans un fichier séparé: %geo-path%/toolkit-{land->id}.pdef.xml
[3] .
%geo-path%
est une variable du géorama. Cette variable est
définie dans la section <Vars>…</Vars>
.
Voyons pour notre cas ce qui est déclaré dans cette section :
<Vars> <Var name="geo-path"><![CDATA[/../config]]></Var> <Var name="editors"><![CDATA[admin;webmaster]]></Var> </Vars>
Nous y découvrons que la variable %geo-path%
pointe vers le
répertoire au-dessus de la racine du site[4] , sous-répertoire
config
. À ce stade, on peut donc dire que le href
équivaut à /../config/toolkit-{land->id}.pdef.xml
.
Il nous reste à expliquer l'étrange expression
{land->id}
au sein de
/..config/toolkit-{land->id}.pdef.xml
. C'est une
substitution dynamique [5] qui sera transformée
par l'ID du noeud <Land>…</Land>
, ici
/toolkit/index.php
. On pourrait dès lors penser que l'expression
href="%geo-path%/toolkit-{land->id}.pdef.xml">
serait équivalente à /../config/toolkit-toolkit/index.php.pdef.xml
.
Vous n'avez pas tort mais ici on a affaire à un cas un peu spécial car
il s'agit d'une page qui se trouve dans un sous-répertoire du site. Dans ce
cas le {land-id}
est substitué par index.php
(on ne
garde que la partie finale). Le résultat est donc
/../config/toolkit-index.php.pdef.xml
.
Pas difficile de se souvenir de tout cela quand on travaille à la création d'une page. Cela devient un peu plus embêtant quand la page a été créée il y a un certain temps car comment se souvenir de tout cela. C'est ici qu'intervient le fameux "Who Am I?".
Le "Who Am I?" permet, rien qu'en regardant la source d'une page de savoir
dans quel fichier physique cette page a été définie (on parle ici de la
définition de la page et non de son contenu). On peut donc, rien qu'à voir
la source de la page savoir que sa définition est issue du fichier
/../config/toolkit-index.php.pdef.xml
et cela en utilisant
une autre substitution dynamique de Vae Soli! dans le commentaire associé
à une île de la page. Voici comment :
Line 001…<Contents id="contents" class="rigolo"> Line 002… <Archipelago id="body" active="yes" category="body"> Line 003… <Island id="body-core" active="yes" class="LSContents" lupdate="auto"> Line 004… <role-mapping role="editor" groups="admin" /> Line 005… <param name="comment"><![CDATA[{page-href}]]></param> Line 006… <param name="storage"><![CDATA[%iles%/toolkit-{land->id}_{page->lang}.php]]></param> Line 007… </Island> Line 008… </Archipelago> Line 009…</Contents>
La réponse se trouve en ligne 005 : demander un commentaire sur une île
avec la substitution dynamique {page-ref}
génère le commentaire
suivant juste avant l'affichage de l'île :
<!-- WhoAmI: toolkit-index.php.pdef.xml -->
Nous laissons à vos soins de savoir où le fichier est déployé (nous ne donnons pas ces infos pour des questions de sécurité).
[1] … Voir l'objet de classe LSBrowser
[2] … Seeing into one's true nature
[3] … pdef = Page Definition
[4] … Pointer vers un répertoire au-dessus de la racine du site est important pour bénéficier d'un bon niveau de sécurité.
[5] … Vae Soli!possède de multiples substitutions dynamiques à différents endroits. C'est une manière aisée, par le biais d'une même expression d'obtenir des valeurs diverses.