Niouzes

< Octobre 2021 >
Lu Ma Me Je Ve Sa Di
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Citation

Attention

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.

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

Table Of Contents

  1. Template with patterns, Swipe Simply, cahing pages for bots, … (06/08/2014)
  2. Gestion de redirections, Accept-Language, extrapolation de la langue et du pays, LSContainer et le génome, LSInput et les gènes, utilisation de LSCacheDir, création de propriétés dynamiques de LSPage dans le géorama, … (11/10/2013)
  3. Statistiques d'accès, Site Manager, prefetch, prerender, File Explorer, interactions Ajax … (17/06/2013)
  4. LSTag, LSContentsDatetime, LSContentsCountdown, LSContentsStopwatch, threshold et score, configuration vhosts Apache, génération automatique, LSVStrings.js, LSVDates.js, tracing sur XML des îles, Free User Input Zones, multiple credentials, cookie de dernière visite, LSInput et datalist (10/04/2013)
  5. Tour d'horizon des filtres (23/09/2013)
  6. Messages de service (07/01/2014)
  7. Accès aux propriétés des îles, halt.sem, cookies positionnés dans les îles, filtre 'browsertype', contenus alternatifs, expressions PHP sur les href, gestion de l'expiration, filtre de visite, ... (22/09/2013)
  8. Messages de service, ... (30/10/2012)
  9. Config Apache, LSInput, LSForm, ... (13/03/2013)
  10. LSContentsBooking, Browser Danger Rating, User Agent vides (non spécifiés), filtres sur les paramètres, LSBrowser, ... (11/06/2013)
  11. LSTag('img'), auto pages, nouveaux filtres, audio/video, ... (02/11/2013)
  12. LSGeo, LSFootnotes, LSSourceFile, LSPublication, onfail avec codes de retour HTTP (301, 302, ...), ... (27/06/2013)
  13. LSCache, microformat (lupdate), multicontent, LSContentsTagCloud, LSContentsImageGallery, HTML5 (input zones), ... (15/09/2013)
  14. Check Spamhaus, vos settings dans le géorama, LSContentsMicronews, Switch dans le géorama, LSCursor: des records dans les records, ... (04/12/2012)
  15. Campagnes de pub, TODO list (04/12/2012)
  16. Debugging de page, LSTimeline, le fichier de géorama, LSTag, Glossaire IT, Named colors, Codes langue, ... (23/03/2013)
  17. LSCursor: une revue complète de la classe (12/03/2013)
  18. LSForm, LSInput, … (28/01/2013)
  19. LSContentsBusinessCoordinates, redirection de pages, LSTwitterPost, LSContentsTwitterFollowers, LSContentsShare, calendrier, LSContentsContactForm, LSContentsReview et LSReview, droits sur une page, URLs canoniques, LSPaymentOptions et LSContentsPaymentOptions, Offres d'emploi, LSContentsImageTransition, ... (20/09/2013)
  20. Galerie avec vignettes, RSS, partage d'offres d'emploi, partage de citations, diaporama dewslider, horloge flash, footnotes, ... (01/10/2012)
  21. îles préfixées de texte standard, le paramètre 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)
  22. LSContentsLoginLogoff, Utilisation de && dans les conditions des îles, LSWidgetOpeningHours et LSContentsBusinessOpeningHours, inclusion de snippets, image bouton de login/logoff, LSContentsBusinessCoordinates, commentaires dans les îles, doctypes, LSImageTrans, calcul de dates, LSWidgetEmailForm, LSContentsMedia, LSContentsIFrame, onload et onunload d'une page, Page settings, ... (22/09/2013)
  23. Dates et heures de publication et/ou d'expiration, PHP expressions, Blocs XHTML avant et après une île, suite de pages, îles valables par domaine, substitutions, envoyer des fichiers au serveur, templates dynamiques, contenus distants, contenus générés en Java, LSCalculator, Gérer des signets (bookmarks), Pages conditionnelles, îles conditionnelles, désactivations, LSContentsMedia, taille du géorama, partager une page entre sites, LSXHtmlImg, île dans la section …, textes latins, Dublin Core, Utilisation de caches, corrections automatiques, In-Place Editing, LSContentsCitation (03/11/2013)

Same tracing options 2013-10-11

Depuis l'opus "5.0.0012"

Vae Soli! has two places where the tracing options can be set :

  1. In the georama
  2. In a page

This deserves some explanations ! When a page is requested, there are few elements that are created before the page gets rendered : an instance of a Vae Soli! application is created, which in turns creates an instance of a georama (the complete map of the site being queried), and eventually the requested page.

At the time the application is created, the page object is still completely unknown. Same thing when the georama gets created. Still … you as a developer you probably want to be able to log few items already. Where ? With what level of granularity ? With what filter on it ? Moreover, you may also want different options for the very start of the whole process (the application object + the georama object) and for the rendering of the page. Well, these are the very reasons why there are two places where tracing options can be set. Great !

Settings in the georama

<?xml version="1.0" encoding="iso-8859-1"?>
<Georama xmlns:xi="http://www.w3.org/2001/XInclude" version="4.0">
    <xi:include href="sitedesc.xml" />

    <Vars>
        <Var name="geo-path" landscape=""><![CDATA[/../georama]]></Var>
        <Var name="iles"><![CDATA[/islands]]></Var>
    </Vars>

    <Settings id="georama">
        <LSTracingLevel><![CDATA[48]]></LSTracingLevel>
        <LSTracingOutput><![CDATA[/traces.log]]></LSTracingOutput>
        <LSTracingFilter><![CDATA[]]></LSTracingFilter>
    </Settings>

    …
</Georama>

Settings in the page (via defaults.xml)

<Defaults>
    <LSDoctype><![CDATA[html5]]></LSDoctype>

    <LSTracingLevel><![CDATA[48]]></LSTracingLevel>
    <LSTracingOutput><![CDATA[/traces.log]]></LSTracingOutput>
    <LSTracingFilter><![CDATA[]]></LSTracingFilter>

    <LSPerfThreshold><![CDATA[0.050]]></LSPerfThreshold>

    <LSTemplate><![CDATA[/template/vaesoli.html]]></LSTemplate>
    <LSTheme><![CDATA[hello]]></LSTheme>

    …
</Defaults>

Great ! But then it immediately raises a new question…

How can I synchronize these values ? If we have two places to update the settings, the risk is high that these get desynchronized rapidly at a time they shouldn't. Well this is the very reason why we provide the "SAME" mechanism.

<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>

    …
</Defaults>

Problem solved.

Images with srcset attribute 2013-10-05

Since opus "5.6.0001"

In an Editor's Draft of 5 October 2013, W3C has published a first specificcation of the srcset attribute, an HTML extension for adaptive images. We here quote W3C's website:

When authors adapt their sites for high-resolution displays, they often need to be able to use different assets representing the same image. We address this need for adaptive, bitmapped content images by adding a srcset attribute to the img element.

As of , Vae Soli! has brought support for this very new extension of the HTML5 markup via the $szSrcset property of the img tag:

$oP = new LSTag();
$oP->szStyle = 'text-align:center;';
$oImg = new LSTag('img');
$oImg->szSrc = '/vaesoli/resources/images/continent.jpg';
$oImg->szSrcset = '/vaesoli/resources/images/continent-low.jpg 1x, ' .
                  '/vaesoli/resources/images/continent-high.jpg 2x';
$oP->AddObject($oImg );
echo $oP;

… which gives…

Given the fact that this addition to HTML5 is quite recent (remark of ), support for this feature in various browsers is still lacky.

You can consult the Vae Soli! documentation of the srcset support.

Islands built with PHP code straight away 2013-09-24

Since opus "5.6.0000"

The choise is given to apply different strategies when building a georama island. For example, an island can be built with the xhtml strategy or with the html5 strategy. The most common strategy is the class strategy. One new strategy has appeared in Vae Soli! opus 5.6.0000 : the php strategy. Here are examples of such strategies :

xhtml strategy :

<Island id="example" active="yes" xhtml="yes">
    <p>Hello World</p>
</Island>

For the xhtml strategy to be applied correctly, it must all form valid XML and must NOT be included in a CDATA section. Please note that such content cannot be modified via the "in-place editing" features of Vae Soli!: it must be edited via a direct modification of the georama.

html5 strategy :

<Island id="example" active="yes" html5="yes"><![CDATA
    <h2>My title</h2>
    <p>Hello World</p>]]>
</Island>

For the html5 strategy to be applied correctly, it MUST be included in a CDATA section. Please note that such content cannot be modified via the "in-place editing" features of Vae Soli!: it must be edited via a direct modification of the georama.

class strategy :

<Island id="example" active="yes" class="LSContents">
    <param name="storage"><![CDATA[/islands/mycontent.php]]></param>
</Island>

Such content CAN be edited via "in-place editing" features … as long as the class itself complies with such techniques (and that the current user is part of the group which is granted "editing" rights).

php strategy :

This is the new strategy we have introduced with opus 5.6.0000 :

<Archipelago id="breadcrumb" active="yes" category="before-body">
    <Island id="breadcrumbs" active="yes" php="yes"><![CDATA[
        $aPages = $this->oApp->oPage->WhereHaveYouBeen();

        if ( count( $aPages ) > 0 )
        {
            echo "<h2>Where Have You Been? <q>It's alright "    .
                 "we know where you've been…</q> "              .
                 "<cite>Pink Floyd</cite></h2>";
            $szBreadCrumbs = '';

            foreach ( $aPages as $szPage => $aProps )
            {
                $szBreadCrumbs .= "<a href=\"$szPage\">$szPage</a>, ";
            }
            $szBreadCrumbs = STR_Strin( $szBreadCrumbs,2 );
            echo $szBreadCrumbs;
        }
    ]]></Island>
</Archipelago>

For the php strategy to be applied correctly, it MUST be included in a CDATA section. Please note that such content cannot be modified via the "in-place editing" features of Vae Soli!: it must be edited via a direct modification of the georama.

Since this code is actually executed in the context of the georama (LSGeorama) $this refers to the georama ! The georama maintains a reference to the application object (oApp), which maintains in turn a reference to the current page (oPage).

Breadcrumb 2013-09-23

Since opus "5.6.0000"

A new class, the breadcrumb, has come to a reality in Vae Soli!, not that this feature was not programmable before, but now it comes directly with a genuine implementation. The only thing that must be mentioned in the georama is the proper island type :

<Island id="breadcrumb" active="yes" class="LSContentsBreadcrumb">
    <param name="title"><![CDATA[Where Have You Been? 
    <q>It's alright we know where you've been</q> 
    <cite>Pink Floyd</cite>]]></param>
    <param name="separator"><![CDATA[ &#8594; ]]></param>
</Island>

Direct access to the documentation of LSContentsBreadcrumb.

Mention de l'auteur d'une île 2013-09-08

Depuis l'opus "5.4.0015"

Avec la version 5.4.0015 il est désormais possible d'afficher l'auteur principal d'une île. Cela se fait avec l'attribut author="..." de l'île comme l'illustre le cas suivant :

<Island id="body-core" active="yes" class="LSContents" 
        lupdate="auto" author="Pat Y. Boens" cdate="yes">
    <role-mapping role="editor" groups="admin" />
    <param name="comment"><![CDATA[{page-href}]]></param>
    <param name="storage"><![CDATA[%iles%/articles-fr.php]]></param>
</Island>

Pour bénéficier de cet affichage il faut que lupdate soit indiqué ainsi que author. Le cas ci-dessus vous donne un exemple de positionnement de ces deux attributs.

LSContainer implémente un génome 2013-09-05

Depuis l'opus "5.4.0015"

Vae Soli! 5.4.0015 implémente la notion de génome dans les conteneurs. De quoi s'agit-il ?

L'idée est empruntée à la mise au point d'algorithmes génétiques, comme le terme génome le laisse entendre. Le génome dirige l'activation ou l'inhibition des contrôles en fonction des gènes dont ils font montre.

Désormais les objets LSContainer (LSForm hérite de LSContainer !) sont affublés d'un génome. Vide par défaut (null).

Le changement opéré dans Vae Soli! est lié justement au génome en question. Si un génome est renseigné, alors il est vérifié. Cette implémentation respecte parfaitement la compatibilité ascendante.

Ainsi donc lorsque le génome n'est pas vide, il faut que les objets inclus dans le conteneur fassent montre d'un gène spécifique pour être exprimés. En d'autres termes, un formulaire possédant un génome donné laissera s'exprimer tous les contrôles (des zones d'input par exemple, des libéllés, …) pour aurant qu'ils possèdent un gène précis.

Une variation dans le génome du formulaire aura pour conséquence de voir une zone incluse ou non dans le formulaire en fonction du gène que cette zone souhaite exprimer.

Cela semble compliqué ? Pas tant que cela en fait, et techniquement c'est même plutôt simple. Allez … un exemple en pseudo-code est nécessaire :

$oForm              = new LSForm(…);
$oForm->szGenome    = "MOBILE-WEB";

$oZone1             = new LSInput( … );
$oZone1->aGenes     = array( "MOBILE","WEB" );

$oZone2             = new LSInput( … );
$oZone2->aGenes     = array( "MOBILE" );

$oForm->AddObject( array( $oZone1,$oZone2 ) );

echo $oForm;

Ce que cet exemple illustre c'est un formulaire dont le génome est "MOBILE-WEB" avec deux zones qui possèdent les gènes "MOBILE" et "WEB" pour la première et "MOBILE" pour la deuxième. Dans ce cas précis, le formulaire laisse s'exprimer les deux zones. Si on modifiait à présent le génome du formulaire en "MOBILE", les deux zones $oZone1 et $oZone2 seraient toujours rendues dans le formulaire car toutes les deux possèdent le gène "MOBILE". Par contre, la modification du génome en "WEB" ne laisserait plus s'exprimer QUE $oZone1 car seule cette zone possède le gène "WEB".

Voici un code réel à peine différent du pseudo-code préenté plus haut :

$oForm              = new LSForm( 'frmGeneExample' );
$oForm->szGenome    = 'MOBILE-WEB';

$oZone1             = new LSInput( 'text','txtZone1','txtZone1' );
$oZone1->szTrailer  = "\n";
$oZone1->aGenes     = array( 'MOBILE','WEB' );

$oZone2             = new LSInput( 'text','txtZone2','txtZone2' );
$oZone2->szTrailer  = "\n";
$oZone2->aGenes     = array( 'MOBILE' );

$oForm->AddObject( array( $oZone1,$oZone2 ) );

echo $oForm->Render();

En voici le résultat généré :

<form action="/news.php" method="post" id="frmGeneExample">
<input type="text" value="" id="txtZone1" name="txtZone1" tabindex="1" />
<input type="text" value="" id="txtZone2" name="txtZone2" tabindex="2" />
</form>

Changeons le génome du formulaire à présent :

$oForm->szGenome = 'WEB';

Voyons le résultat du rendu du formulaire pour le génome 'WEB' :

<form action="/news.php" method="post" id="frmGeneExample">
<input type="text" value="" id="txtZone1" name="txtZone1" tabindex="1" />
</form>

Comme on le constate, la modification du génome influence le rendu du formulaire. Bien entendu, la beauté de l'exercice ne se cantonne pas à parler de génome et de gènes : cela correspond à un réel besoin sur le terrain !

La variation du génome peut aussi être envisagée de manière totalement dynamique. Le pseud-code suivant vous montre en quoi :

If device is mobile
    $oForm->szGenome = 'MOBILE';
else
    $oForm->szGenome = 'WEB';

… et ici le choix du génome reste d'une simplicité extrême ! Imaginez des variations au hasard, imaginez des conditions plus complexes, imaginez des variations dont le succès (reward) est couplé à l'A/B Testing de Vae Soli!, … bref une multitude de champs à ouvrir.

Utilisation de LSCacheDir 2013-08-23

Depuis l'opus "5.4.0011"

La classe LSCache utilise automatiquement un répertoire de caching qui est propre au framework.

Vous pouvez néanmoins décider d'indiquer à Vae Soli! un répertoire qui vous est propre (pour des questions de sécurité par exemple). Rien de plus simple. Il suffit en effet de mentionner ce répertoire dans la configuration de Vae Soli!. Ici, nous avons inclus une ligne dans le fichier defaults.xml :

<LSCacheDir><![CDATA[/../cache/]]></LSCacheDir>

Cela permet dans le cas présent d'utiliser un répertoire de cache qui se trouve au-dessus de la racine du site (sécurité, quand tu nous tiens ! ! !)

Création de propriétés dynamiques 2013-08-02

Depuis l'opus "5.4.0011"

Vae Soli! utilise une gestion "orientée objets" de son géorama. En d'autres termes, une page peut être définie sur base d'une classe et une classe peut hériter d'une autre classe.

C'est extrêmement pratique puisque dès lors les pages peuvent tout simplement hériter de toutes les caractéristiques définies dans la classe dont elles dépendent. Et comme les classes peuvent elles-mêmes hériter des caractéristiques d'autres classes cela permet de concevoir des pages dont la définition est minimale : en fait, on ne spécifie que les différences et le tour est joué.

À ce mécanisme de base vient s'ajouter à présent la possibilité de créer des propriétés dynamiques dans les pages. Voyez plutôt :

<Land id="/login.php;/quitus/pages/login.php"
      group="{main}"
      creationdate="20110213"
      lupdate="auto"
      condition=""
      inherit="login">
</Land>

Ce que vous voyez là c'est la définition de la page de login. Vous le constaterez volontiers, cette définition est vraiment minimale. Nous avons cependant mis en évidence que cette page est définie sur base de la classe login. La question se pose dès lors de connaître la définition de la classe login. Voici cette définition :

<Class id="login" 
       inherit="public"
       properties="login_required=true">
</Class>

Comme nous le voyons, la classe login hérite de la classe public. Un passage par ladite classe public s'impose donc et comme vous allez le constater, c'est là que se trouve toute la définition de la page dont tous les détails n'ont d'ailleurs, pour cette démonstration, aucune importance :

<Class id="public" 
       group="{main}" 
       lupdate="auto" 
       active="yes" 
       editable="yes">
  <Defaults>
    <Settings>
      <LSSubstitutions><![CDATA[%geo-path%/substitutions.xml;
        %geo-path%/abbr.xml;
        %geo-path%/autocorrect.xml;
        %quitus-root%/q-dict.xml;
        %quitus-root%/resources/q-themes.xml]]></LSSubstitutions>
    </Settings>
  </Defaults>
  <Contents>
    <Archipelago id="validate" 
                 active="yes" 
                 category="validate">
        <xi:include href="validate.xml" />
    </Archipelago>
    <Archipelago id="language-switchers" 
                 active="yes"
                 category="Q-ls">
      <Island id="language-switchers" 
              active="yes" 
              class="LSContentsLanguageSwitchers">
        <param name="languages"><![CDATA[fr;nl;en;de;it;pt]]></param>
      </Island>
    </Archipelago>
    <Archipelago id="animation" active="yes" category="Q-anim">
      <Island id="animation" active="yes" class="LSContents">
        <param name="storage"><![CDATA[%q-islands%/{archipelago->id}-{page->lang}.php]]></param>
      </Island>
    </Archipelago>
    <Archipelago id="headline" active="yes" category="Q-headline">
      <Island id="headline" active="yes" class="LSContents">
        <param name="storage"><![CDATA[%q-islands%/{archipelago->id}-{page->lang}.php]]></param>
        <param name="with-div">false</param>
      </Island>
    </Archipelago>
    <Archipelago id="font-sizer" active="yes" category="Q-fs">
        <Island id="fontsizer" active="yes" class="LSContentsFontSizer" />
    </Archipelago>
    <Archipelago id="silos" active="yes" category="Q-silos">
        <Island id="silos" active="yes" class="LSContents">
            <param name="storage"><![CDATA[%q-islands%/{archipelago->id}-{page->lang}.php]]></param>
        </Island>
    </Archipelago>
      <Archipelago id="footer" active="yes" category="Q-footer">
        <Island id="footer" active="yes" class="LSContents">
            <param name="storage"><![CDATA[%q-islands%/{archipelago->id}-{page->lang}.php]]></param>
        </Island>
      </Archipelago>
      <Archipelago id="sysmenu" active="yes" category="Q-smenu">
          <Island id="sysmenu" active="yes" class="LSContents">
              <param name="storage"><![CDATA[%q-islands%/{archipelago->id}-{page->lang}.php]]></param>
          </Island>
      </Archipelago>
      <Archipelago id="social" active="yes" category="social">
          <xi:include href="social-networks.xml" />
      </Archipelago>
      <Archipelago id="link" active="yes" category="link">
          <!-- <xi:include href="link.xml" /> -->
          <Island id="link" active="yes" xhtml="yes" landscape="www.latosensu.be;www.latosensu.org;www.latosensu.net;www.ls.poc;www.fastwrite.com;www.fastwrite.be;www.fw.poc">
              <link rel="stylesheet" type="text/css" media="screen,projection,print" href="{{{res}}}/vaesoli/css/vaesoli.css" />
              <link rel="stylesheet" type="text/css" media="screen,projection,print" href="{{{res}}}/css/homepage.css" />
              <link rel="stylesheet" type="text/css" media="screen,projection,print" href="{{{res}}}/css/inside.css" />
              <link rel="stylesheet" type="text/css" media="handheld" href="{{{res}}}/css/handheld.css" />
          </Island>
          <!-- <Island id="link" active="yes" xhtml="yes" landscape="www.quitus.be;www.quitus.ch;www.quitus.es;www.quitus.poc;www.q.poc">
              <p>NOT SUPPORTED</p>
          </Island> -->
      </Archipelago>
      <Archipelago id="meta" active="yes" category="meta">
          <xi:include href="meta.xml" />
      </Archipelago>
      <Archipelago id="poles" active="yes" category="poles">
          <xi:include href="poles.xml" />
      </Archipelago>
      <Archipelago id="ecma" active="yes" category="ecma">
        <Island id="ecma" active="yes" xhtml="yes">
          <script type="text/javascript" src="/vaesoli/scripts/LSVStrings.js"> </script>
          <script type="text/javascript" src="/vaesoli/scripts/LSVStorage.js"> </script>
          <script type="text/javascript" src="/vaesoli/scripts/LSVDates.js"> </script>
          <script type="text/javascript" src="/vaesoli/scripts/LSVCookies.js"> </script>
          <script type="text/javascript" src="/vaesoli/scripts/LSVMisc.js"> </script>
          <script type="text/javascript" src="/vaesoli/scripts/LSVDom.js"> </script>
          <script type="text/javascript" src="/scripts/ls.js"> </script>
        </Island>
      </Archipelago>
      <Archipelago id="user-styles" active="yes" category="user-styles">
          <Island id="user-styles" active="yes" class="LSContents">
              <param name="storage"><![CDATA[/islands/user-styles.php]]></param>
              <param name="with-div">false</param>
          </Island>
      </Archipelago>
      <Archipelago id="system-menu" active="yes" category="system-menu">
          <Island id="menu" active="yes" class="LSContents">
              <role-mapping role="editor" groups="admin" />
              <param name="storage"><![CDATA[/template/system-menu.php]]></param>
          </Island>
      </Archipelago>
      <Archipelago id="navmenu" active="yes" category="navmenu">
          <xi:include href="navmenu.xml" />
      </Archipelago>
      <Archipelago id="sidebar" active="yes" category="sidebar">
          <xi:include href="calendar.xml" />
          <xi:include href="citation.xml" />
          <Island id="weather" active="yes" class="LSContentsWeather" ip="127.0.0.2">
              <role-mapping role="editor" groups="admin"/>
              <param name="lat"><![CDATA[50.466667]]></param>
              <param name="lon"><![CDATA[4.183333]]></param>
          </Island>
          <Island id="honeypot" active="yes" xhtml="yes">
              <div style="display:none;"><a href="http://www.latosensu.be/honeypot/honeypot.php">lifetime-episode</a></div>
          </Island>
      </Archipelago>
      <Archipelago id="quick-links" active="yes" category="quick-links">
        <Island id="quick-links" active="yes" class="LSContents">
          <role-mapping role="editor" groups="admin" />
          <param name="storage"><![CDATA[/template/quick-links.php]]></param>
          <param name="with-div"><![CDATA[false]]></param>
        </Island>
      </Archipelago>
      <Archipelago id="add-bookmark"  active="yes" category="add-bookmark">
        <xi:include href="add-bookmark.xml" />
      </Archipelago>
      <Archipelago id="panel" active="yes" category="panel">
        <xi:include href="logon.xml" />
      </Archipelago>
      <Archipelago id="sysmenu" active="yes" category="sysmenu">
        <xi:include href="sysmenu.xml" />
      </Archipelago>
      <Archipelago id="mission" active="yes" category="mission">
        <xi:include href="mission.xml" />
      </Archipelago>
      <Archipelago id="summary" active="yes" category="summary">
        <xi:include href="social-networks.xml" />
        <xi:include href="follow-us-on-twitter.xml" />
        <Island id="summary-core" active="yes" class="LSContents">
            <role-mapping role="editor" groups="admin" />
            <param name="storage"><![CDATA[/islands/home_core_summary_{page->lang}.php]]></param>
        </Island>
        <Island id="bookmarks" active="yes" class="LSContentsBookmarks">
            <param name="callback-pre"><![CDATA[startRounded]]></param>
            <param name="callback-post"><![CDATA[stopRounded]]></param>
        </Island>
      </Archipelago>
      <Archipelago id="langswitchers" active="yes" category="langswitchers">
          <Island id="switchers" active="yes" class="LSContentsLanguageSwitchers">
              <param name="languages"><![CDATA[fr,en]]></param>
          </Island>
      </Archipelago>
      <Archipelago id="silos-menu" active="yes" category="silos-menu">
          <Island id="silos-menu" active="yes" class="LSContents">
              <param name="storage"><![CDATA[/template/silos-menu.php]]></param>
          </Island>
      </Archipelago>
  </Contents>
</Class>

Bien … toute la partie mise en bleu n'a aucune importance pour notre explication concernant les propriétés dynamiques. Par contre, pour le contenu réel de la page c'est effectivement LA définition qui donne tout le contenu nécessaire. Concentrons-nous à présent sur la partie mise en rouge, soit :

<Class id="public" 
       group="{main}" 
       lupdate="auto" 
       active="yes" 
       editable="yes">

Comme vous le constatez, la classe, outre sa définition (la partie bleue) possède des caractéristiques ou propriétés (partie rouge).

Ces propriétés sont automatiquement injectées aux pages dont la définition dépend, de manière directe ou héritée, de la classe public. Or, souvenez-vous, la page de login hérite de la classe login qui elle-même hérite de la classe public. Il en découle donc que le groupe, la date de dernière mise à jour, et les propriétés "active" et "éditable" de la page sont positionnées.

Mais comme dans toute bonne orientation objets, ces propriétés peuvent être écrasées et remplacées par la classe login (spécialisation de la classe public). Voyons dès lors si c'est le cas :

<Class id="login" 
       inherit="public"
       properties="login_required=true">
</Class>

Et bien non ! Aucune de ces propriétés n'est finalement repositionnée dans la classe login par contre on voit une nouvelle propriété faire son apparition : properties="login_required=true". Et bien c'est ainsi qu'on peut créer de nouvelles propriétés dans la page courante. Ce que la propriété properties suggère c'est qu'une liste de propriétés de l'objet page (LSPage) peut ainsi être traitée. Il est possible de positionner plusieurs propriétés : il suffit de séparer les propriétés par un ";". La syntaxe est assez immédiate et parfaitement naturelle :

property=value

Dans notre exemple, la page courante (ici la page de login) recevra une toute nouvelle propriété login_required et nous assignerons à cette propriété la valeur "true", une chaîne de caractères. Fin de la démonstration. Faites-en maintenant le meilleur usage.

Utilisation du Accept-Language de la requête HTTP 2013-06-27

Depuis l'opus "5.4.0002"

Vae Soli! accepte désormais l'utilisation de l'entête Accept-Language de la requête HHTP pour déterminer la langue de l'utilisateur lors de sa toute première visite. En cela, Vae Soli! suit les recommandations fournies par le W3C en matière d'internationalisation: Accept-Language used for locale setting.

L'idée poursuivie est la suivante : est-ce une bonne idée d'utiliser le header HTTP Accept-Language pour déterminer la langue de l'utilisateur ? La réponse fuse : oui, mais il faut donner la possibilité à l'utilisateur d'outrepasser vos suppositions !

Auparavant, le setting <LSLanguage>…</LSLanguage> de Vae Soli! vous permettait d'indiquer la langue dans laquelle une page devait être servie (voire même la totalité d'un site) … du moins lors de la toute première visite de l'utilisateur. Après la première visite, plus de souci car la langue courante avait été stockée en cookie et le cookie était réutilisé pour chaque visite postérieure. Le cas qui nous occupe est donc la toute première visite.

Dans le cas précis de la toute première visite, le setting <LSLanguage>fr</LSLanguage> permet par exemple de dire "par défaut, cette page est à servir en français". Or le visiteur est peut-être néerlandophone alors même qu'une version néerlandophone de la page était disponible. Pas de chance ! Cet utilisateur-là, vous ne l'aviez jamais vu avant et vous lui servez la page en français ! Désormais vous pouvez mieux vous adapter à ce besoin. Voci comment :

<LSLanguage><![CDATA[accept=fr]]></LSLanguage>

En soi, il suffit d'expliquer la partie accept= de l'option. En effet, pour le reste, le comportement est identique au passé : si on ne peut rien déterminer du tout, alors servir la page en français. Par contre, là où la valeur accept entre en jeu c'est que désormais Vae Soli! va regarder dans les headers HTTP pour voir s'il peut déterminer la langue à utiliser : Vae Soli! va s'intéresser au header Accept-Language ! Voyons cela dans le détail en prenant example sur la requête HTTP de la présnete page (faite depuis un de nos PCs de développement local) :

GET /samples.php HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 6.1; WOW64)
  Presto/2.12.388 Version/12.15
Host: www.vaesoli.poc
Accept: text/html, application/xml;q=0.9, application/xhtml+xml,
  image/png, image/webp, image/jpeg, image/gif,
  image/x-xbitmap, */*;q=0.1
Accept-Language: fr-BE,fr;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate
…

On remarque dans la requête que le navigateur a positionné une langue possible à fr. Si cette valeur (fr) est une valeur qu'on supporte, alors servons la page dans la langue indiquée ! Rien de plus simple. Au demeurant, si la langue en question ne peut être servie alors le navigateur a aussi indiqué que l'anglais pouvait faire l'affaire : c'est la valeur en. On sait par ailleurs que le navigateur indique une préférence pour le français (ce n'est pas l'ordre d'apparition qui compte mais la qualité : q=0.9 pour le français contre un q=0.8 pour l'anglais). Mais nous avons paré au plus simple dans Vae Soli!, du moins pour l'opus 5.4.0002, et nous nous servons de la 1ère langue mentionnée (par ordre d'apparition).

Donc, nous extrayons la langue du header HTTP (par ordre d'apparition) et il nous reste à savoir si telle est une langue que nous supportons (car quid de celui dont le navigateur indique que sa langue est le danois alors que nous n'avons pas de contenu danois pour la page ?). Une fois de plus, c'est simple : il vous suffit d'indiquer les langues supportées par votre site et cela se fait via le nouveau setting <LSAcceptedLanguages>…</LSAcceptedLanguages> :

<LSLanguage><![CDATA[accept=fr]]></LSLanguage>
<LSAcceptLanguages><![CDATA[fr;en;nl;it;pt;de]]></LSAcceptLanguages>
<LSRegionSubtag><![CDATA[BE]]></LSRegionSubtag>

Si le header HTTP Accept-Language indique que sa première langue (ordre d'apparition, nous le rappelons) est une valeur comprise dans fr;en;nl;it;pt;de, alors c'est cette langue qui sera servie ! Voilà comment Vae Soli! se sert à présent du header HTTP pour positionner la langue au meilleur choix possible.

Bien entendu, l'équipe de Vae Soli! continuera les développements pour voir tenir compte des préférences (q=0.9, …) et nous vous tiendrons informés du moment de sa disponibilité.

Prise en compte de <LSAcceptLanguages><![CDATA[…]]></LSAcceptLanguages> dans l'utilisation de l'île LSContentsLanguageSwitchers 2013-08-30

Depuis l'opus "5.4.0012"

Vae Soli! possède une paramétrisation concernant les différentes langues acceptables sur un site web. Il s'agit du paramètre LSAcceptLanguages très souvent renseigné dans les éléments de configuration généraux à savoir dans le fichier defaults.xml. En voici un exemple :

<Defaults>
    <Settings>
        <!-- Default settings for all other domain names -->
        <LSDoctype><![CDATA[xhtml11]]></LSDoctype>
        <LSIsDebug><![CDATA[true]]></LSIsDebug>
        <LSCacheTTL><![CDATA[0]]></LSCacheTTL>
        <LSLanguage><![CDATA[fr]]></LSLanguage>
        <LSTheme><![CDATA[serenity]]></LSTheme>

        <LSTracingLevel><![CDATA[48]]></LSTracingLevel>
        <LSTracingOutput><![CDATA[/logs/traces.log]]></LSTracingOutput>
        <LSTracingFilter><![CDATA[]]></LSTracingFilter>
        <LSPerfThreshold><![CDATA[0.050]]></LSPerfThreshold>

        <LSTemplate><![CDATA[/template/trebuchet.html]]></LSTemplate>
        <LSTemplateQueryURLOrCookie><![CDATA[false]]></LSTemplateQueryURLOrCookie>
        <LSAuthor><![CDATA[Patrick Boens]]></LSAuthor>
        <LSPreRendering><![CDATA[/globals.php]]></LSPreRendering>
        <LSSetProceduresTo><![CDATA[/template/specific.php]]></LSSetProceduresTo>

        <LSSubstitutions><![CDATA[/georama/substitutions.xml;/georama/translations.xml]]></LSSubstitutions>
        <LSSubstitutionsCacheTTL><![CDATA[86400]]></LSSubstitutionsCacheTTL>

        <LSMustWriteSourceHeader><![CDATA[true]]></LSMustWriteSourceHeader>

        <LSAcceptLanguages><![CDATA[fr;nl]]></LSAcceptLanguages>

    </Settings>

Dans ce cas, pourquoi devoir encore positionner les langues pour lesquelles on veut proposer des language switchers dans l'île de classe LSContentsLanguageSwitchers ? Pourquoi ne pas hériter des langues acceptables pour l'ensemble du site,le fameux LSAcceptLanguages ?

C'est désormais possible. A petits frais. Tout petits. Voyez par exemple comment les langues des language switchers devaient être positionnés dans le temps :

<Island id="switchers" active="yes" class="LSContentsLanguageSwitchers">
    <param name="languages"><![CDATA[fr;nl]]></param>
</Island>

Maintenant vous pouvez faire :

<Island id="switchers" active="yes" class="LSContentsLanguageSwitchers">
    <param name="languages"><![CDATA[auto]]></param>
</Island>

Dès ce moment, vous bénéficiez des langues acceptables pour le site, soit LSAcceptLanguages… pour autant que ces langues aient effectivement été positionnées.

Vae Soli! va même un peu au-delà. En effet, vous pouvez aussi vous assurer contre des paramétrages globaux qui seraient incorrects (par exemple, Une modification intempestive du paramètre <LSAcceptLanguages>…</LSAcceptLanguages> sur une page donnée (n'oublions pas que les paramètres généraux — valables pour toutes les pages — peuvent toujours être affinés page par page). Et voilà comment prendre cette assurance complémentaire :

<Island id="switchers" active="yes" class="LSContentsLanguageSwitchers">
    <param name="languages"><![CDATA[auto;fr;nl]]></param>
</Island>

Vae Soli! comprend cette confirguration comme étant "prendre les paramètres généraux indiqués dans <LSAcceptLanguages>…</LSAcceptLanguages>, mais si jamais on avait un souci avec ce positionnement, alors il faut appliquer les langues fr;nl comme étant les langues par défaut.

Utilisation du Accept-Language de la requête HTTP pour inférer les données langue et pays du visiteur (si pas déjà connues) 2013-06-27

Depuis l'opus "5.4.0013"

Vae Soli! extrapole aussi le pays et la langue de l'utilisateur courant via le parsing de l'entête Accept-Language de la requête. Cette extrapolation ne se fait QUE SI les mêmes données ne sont pas déjà connues (via le login d'un visiteur, par exemple).

En d'autres termes, dès le chargement de la page, un ensemble de procédures sont lancées par Vae Soli!. L'une de ces procédures est la procédure InitSettings() de l'objet LSPage. Dans ladite procédure un appel est maintenant réalisé à la toute nouvelle méthode GetAcceptLanguages() (04-09-13 18:31) qui se charge de faire le parsing fin de l'entête Accept-Language de la requête et c'est là qu'on détermine d'ailleurs les langue et pays. Si au moment de rentrer dans GetAcceptLanguages() les propriétés szCountry et szLanguages de l'objet oUser de la page courante sont vides, Vae Soli! les remplit avec les valeurs issues du parsing de l'entête : au lieu de ne rien savoir sur votre visiteur, vous savez au moins que telle est sa langue et tel est son pays [1] .

Par exemple, pour votre cas, nous avons déterminé que votre langue est 'en' et que votre pays est 'US'. Est-ce correct ? Si cela ne l'était pas et que vous êtes un simple visiteur (pas un utilisateur identifié), c'est que les entêtes que fournit votre navigateur 'CCBot' sont incorrectes ('CCBot/2.0 (https://commoncrawl.org/faq/)') et qu'il serait peut-être souhaitable de les modifier.

Pour ceux qui souhaitent un peu plus de documentation sur le sujet de l'entête Accept-Language, voici le lien vers le RFC adéquat.

Gestion de redirections (LSRedirections) 2013-06-27

Depuis l'opus "5.4.0002"

Depuis l'opus 5.0.0003 il vous est possible de mentionner des headers de redirection en cas de onfail. Voyez à ce propos les exemples que nous avons conçus pour vous expliquer ce concept. Ici, Vae Soli! va encore plus loin en vous donnant des mécanismes génériques plus globaux. Ceux-ci peuvent vous faciliter la vie mais ils ne peuvent néanmoins pas se substituer aux possibilités qui vous sont offertes par votre serveur HTTP. Voyez à ce propos la documentation Apache sur le sujet. Quoi qu'il en soit, voyons comment les redirections générales peuvent être traitées en Vae Soli!.

Un nouveau tag de configuration a été établi :

<LSRedirections><![CDATA[%geo-path%/redirections.xml]]></LSRedirections>

Ce que ce setting indique c'est la présence d'un fichier de redirections, un fichier dont on attend qu'il soit un fichier XML. Attention, il s'agit d'un seul fichier et non d'une liste de fichiers ! Voici un exemple de ce type de fichier :

<?xml version="1.0" encoding="iso-8859-1"?>
<Redirections>
    <Redirection active="yes">
        <Pattern><![CDATA[/\/services-core\.php/si]]></Pattern>
        <Location><![CDATA[http://www.vaesoli.org/notfound.html]]></Location>
        <Type><![CDATA[301]]></Type>
        <Message><![CDATA[Moved permanently]]></Message>
    </Redirection>
    <Redirection active="yes">
        <Pattern><![CDATA[/\/hello\.php/si]]></Pattern>
        <Location><![CDATA[http://www.vaesoli.org/sitemap.php]]></Location>
        <Type><![CDATA[307]]></Type>
        <Message><![CDATA[Moved temporarily]]></Message>
    </Redirection>
</Redirections>

Toute la logique se situe dans la partie pattern qui est en fait le pattern d'une expression régulière (preg). Si le pattern en question est trouvé dans le nom du script courant, la redirection prend effet. Sinon la prochaine redirection est examinée.

Le mécanisme est générique et il permet d'effectuer toutes les redirections qu'on souhaite. Cependant, il ne prend pas en compte toutes les URLs pour lesquelles Vae Soli! n'est pas sollicité. Par exemple, les URLs qui ne sont pas trouvées par le serveur HTTP (code 404) ne sollicitent pas Vae Soli!.

Dans les futures versions de Vae Soli! on tiendra compte également de redirections tenant compte du protocole et des domaines/sous-domaines. Stay tuned!, comme on dit.

Notes de bas de page

[1] … Si du moins ces valeurs sont indiquées par le navigateur et si elles sont correctes. Par ailleurs l'indication du pays n'est pas une garantie de la localisation du visiteur: il peut être Belge d'origine flamande (nl-BE) et se trouver en vacances en Espagne.

Précédent Suivant