Le Blog...

Aujourd’hui, quelques réflexions disparates sur le blog lui-même.

1. De la raison d’être d’un Blog

Il n’a de sens (de mon point de vue) qu’en tant que moyen de communication (et non de promotion… n’est-ce pas Jean ?). On ne dit pas tout le temps la même chose à tout le monde. Je pars du principe qu’il y a donc nécessairement dans ces logorrhées des parties que l’on souhaite ne partager qu’avec un sous ensemble de son public habituel.
 
J’ai dans l’idée de répondre à ces enjeux de cibles et de contenu en jouant à deux niveaux différents qui me semblent complémentaires (et tous deux nécessaires). Ces deux mécanismes s’appliquent à des granularités différentes : le Post dans son ensemble et au sein du texte lui-même.

2. Catégories, Canaux de diffusion & Sécurité(s)

Gérer la diffusion du Post lui-même se fait très simplement grâce aux catégories que l’on peut associer à tout Post d’une part et d’autre part par la configuration du site qui héberge le blog.
Exemple de configuration :

  • La page Cuke qui porte le blog lui-même (et où l’on peut ajouter un nouveau Post) n’est accessible qu’à l’auteur et éventuellement d’autres personnes avec lesquelles l’auteur n’a pas de secrets).
  • L’affichage du blog sur cette page est sans restriction : aucun filtre de catégories n’est actif.
  • Des modules d’affichage de Blog sont disposés sur n’importe quelle page du site et filtre les Post par leurs catégories : les ACLs filtrent les utilisateurs et les Catégories filtrent le contenu.
  • Note sur la sécurité
    • C’est le Blog qui est sécurisé : en terme d’ACL on considère que les Posts partagent, héritent, de l’ACL du Blog auquel ils appartiennent.
    • Cela suppose, par exemple, que les liens « lire la suite » (s’ils existent) affichés par le module d’affichage de Blog sont cryptées : un Post n’est pas protégé en soi, il ne l’est que parce qu’un utilisateur lambda ne peut y accéder. Attention, ce n’est pas une réelle protection, il ne s’agit que d’une faible « protection par l’obscurité » en cachant le canal et non l’objet.

D’un point de vue strict, les Posts ne sont réellement sécurisés que via l’ACL du Blog. L’utilisation de la catégorisation est un moyen de gérer la « diffusion multi-canaux », pas de sécuriser le contenu (si vous ne saisissez pas l’importance de cette distinction, demandez moi de vous l’expliquer, c’est crucial J).
Ce choix est un compromis. Rien n’empêche de permettre la définition d’un ACL spécifique au niveau de chaque Post si nécessaire, l’ACL du Blog container étant simplement la protection par défaut.

3. Les appartés

Au sein du texte lui-même, l’idée est de pouvoir facilement faire des apartés à destination d’une ou plusieurs personnes. Le but de ces îlots de contenu est d’apporter en situation, au plus près du contenu général, un éclairage différent en fonction du lecteur, par exemple :

  • Demander l’avis d’un collègue ou d’une communauté sur un point particulier.
  • Aller plus loin dans une explication : un développeur peut dans un aparté faire référence à une implémentation non publique… ou à un bug récent…
  • Faire une « Private joke ».
  • Poser une note pour soi même.

Ce filtrage peut-il reposer sur les catégories ? Non, je ne le pense pas, et ce pour deux raisons :

  • Ces apartés ciblent des lecteurs particuliers, dans des buts divers (cf. ci-dessus) certes, mais toujours à des destinataires explicites.
  • Sémantiquement, le contenu de ces bribes de texte est fondamentalement lié à leur environnement : ils n’apportent pas (ou ne devraient pas apporter) de nouvelles thématiques : ils décorent un contenu, ils se positionnent au niveau pragmatique plutôt que sémantique.

Comment offrir cette possibilité d’apartés à l’auteur ? En encadrant ces apartés par des balises explicites de protection. Ces balises définissent les cibles pouvant lire le contenu : il suffit d’énumérer simplement les noms (login) des utilisateurs (ou les noms des groupes d’utilisateurs) accrédités.
Proposition : [Cuke.Filter Allow="Guillaume, 12531, P.Cuke.G.Supervisors"]aparté[/Cuke.Filter]

4. Conséquences, impacts et effets de bord

Cette capacité introduit une nécessaire étape de parsing préalable à tout affichage mais des optimisations sont possibles en utilisant les attributs des textes html.
Le comportement à l’indexation est simple: aucun aparté ne doit être indexé avec le contenu. Si indexation il doit y avoir, celle-ci doit intégrer totalement la sécurité (les apartés doivent être indexés en tant que documents distincts qui référencent leur texte d’origine).
 
La gestion de la diffusion par catégories est simple et ne pose pas de problèmes particuliers. En revanche, les apartés introduisent nettement plus d’effets de bord. Une option peut être intéressante mais certainement à développer… un jour.

Quand j’entends le mot culture, je sors mon revolver !

Est-ce vraiment Göring qui a dit ça ? Réponse ici : http://tatoufaux.com/spip.php?article398 (vu le nom du site, on devine la réponse). La culture en question en ce qui me concerne est celle de l’utilisateur et du contenu d’un site web. Cela n’a jamais été une problématique simple (et avec les moteurs de recherche, le droit à l’à peu près est oublié).En l’occurrence, il s’agit de sortir un algorithme correct qui prenne simultanément en compte :

  • L’éventuel cookie de l’utilisateur
    • S’il y en a un, il peut être « PubUser » ou non. Un « PubUser » doit être redirigé a minima (pour la cohérence de la navigation) là où pour un non « PubUser » (typiquement un administrateur ou un gestionnaire de contenu), on peut éviter de rediriger.
    • Sans cookie, la requête est considérée comme une requête de moteur.
  • La culture indiquée dans l’url, le cookie ou les informations du navigateur, croisée avec la culture par défaut du portail ou ses cultures actives sans oublier le statut de l’utilisateur qui peut, ou non, avoir le droit de voir toutes les cultures d’un site indépendamment de la restriction que peut apporter un portail.
  • Le nom de domaine qui peut être associé à un portail, avec pour certains utilisateurs (les « PubUser » et les requêtes sans cookie) une redirection systématique vers le nom de domaine du portail (ce qui entraîne la perte de l’éventuel cookie).
  • La présence ou non d’une publication semi-statique (qui dépend de la page exacte et de la culture), celle-ci pouvant n’être qu’une simple réécriture d’url (c’est la page dynamique qui est utilisée).
  • Le mode en cours pour le site (url en .cuke ou utilisation directe de Cuke.aspx).

L’idée générale étant de rediriger vers l’url exacte pour les moteurs (ou toute requête sans cookie), cette url ne devant contenir la culture que pour les cultures qui ne sont pas la culture par défaut.
Ce n’est pas terminé, il manque des tests unitaires et certains mécanismes, notamment en ce qui concerne le filtre sur les cultures actives, la gestion des 404 et la prise de compte des pages virtuelles (K-Item)…
Pas facile la culture...