Besoins

• Il y a des besoins utilisateurs constants pour des extensions puissantes (voir CdmlTable ou CdmlTeX)
• Par principe nous voulons supporter les extensions pour disposer de points-clés de compétitivité
• Le marché et le marketing veulent du WYSIWYG

Strategie

Décisions Stratégiques

• nous contruisons CDML comme une extension unifiée
• nous prenons partie pour qu'il soit disponible à travers une extension de syntaxe (voir "stratégie deux mondes")
• et nous adaptons à des standards de facto de la syntaxe wiki
• nous n'investissons pas activement dans la recherche WYSIWYG,
• nous clonerons le WYSIWIG dès que possible quand de bonnes implémentations seront disponibles.
• WYSIWYG ne peut être seulement qu'une manière partiale parce que les extensions vont bien au delà du style de fonte et de l'indentation de liste

Stratégie des Deux Mondes

Le monde de la syntaxe

nous explorons mais ne poussons pas nos suggestions, nous suivons le courant principal wiki avec un respect des syntaxes

Le monde des extensions

CDML est utilisé pour implémenter efficacement toutes les extensions qui sont demandées. Il n'y a pas de limites à ces extensions.

Les émoticônes comme exemple de la stratégie des deux mondes :

UseSmileys est une option pour activer le support des émoticônes. C'est une option parce que (1) tout le monde ne veut pas des émoticônes et (2) chercher des modèles d'émoticônes coûte un peu de performance. La fonctionnalité AfficherEmoticônes a besoin de chercher un certain nombre de modèles pour les remplacer par des icônes. C'est joli mais cela a un coût et n'est pas extensible à des dizaines ou centaines d'images parce que le coût de recherche pour toutes ces combinaisons de caractères augmente de façon incrémentale. Ce sont des coûts que vous avez sur n'importe quelle page, même si vous n'utilisez pas vraiment les émoticônes. D'un autre côté notre CdmlSymbole : il supporte les mêmes symboles (la syntaxe est un fardeau, aussi nous offrons les deux manières) mais CdmlSymbole ne crée pas de coûts quand il n'est pas utilisé et peut être configuré pour un nombre arbitraire de symboles sans changer cette situation.

Notez l'ambivalence avec d'autres la PluginStrategy d'autres moteurs wiki : l'utlisateur peut choisir et assembler un wiki selon ses besoins mais chaque Plugin crée un peu de charge supplémentaire. Au final, l'utilisateur trouve que son système est devenu bancal et lent... en suivant sa propre liberté de choix et responsabilité.

ProWiki est différent : nous voulons des sytèmes complets qui offrent toutes les fonctionnalités de façon cohérente et à un faible coût. La communauté devrait pouvoir les activer ou les désactiver selon ses besoins fonctionnels, pas parce qu'elle n'aime pas le travail d'installer un plugin ou parce qu'elle n'apprécie guère la pénalité de performance du plugin.

Performance & Efficactié

Il y a une pénalité à supporter 100 syntaxes parce que cela veut dire une centaine de modèles de caractères à chercher.

Il n'y a pas de pénalité à supporter une centaine d'extensions CDML parce qu'il n'y a qu'un passage de reconnaissance à travers le texte wiki (basiquement chercher des "[[") qui reconnaît tous les CdmlElements.

Raisonnement derrière la stratégie

Les faits en rapport :

• HTML
• le HTML n'est pas utilse dans la publication wiki (même s'il est utile, même inévitable pour afficher des pages)
• le HTML est trop compliqué pour le mettre dans les mains des utilisateurs, il créerait aussi une société à deux classes
• le HTML est bien trop incohérent et sans puissance pour implémenter des fonctions puissantes
• La WikiSyntaxe
• n'est pas commode pour supporter beaucoup d'extensions
• beaucoup d'extensions de syntaxe coûteraient de la performance pour la recherche d'expression régulière
• ajouter des extensions rend la syntaxe compliquée et idiosyncrasique
• devient compliquée et idiosyncrasique quand on l'augmente
• Le WYSIWYG est un problème
• la guerre des navigateurs n'offre (n'ofrrira) pas les extensions nécessaires d'Interface Utilisateur
• l'implémentation est trop coûteuse
• Standards
• il n'y a pas de véritables standards de syntaxe, mais des standards de facto
• les extensions devanceront toujours les standards
• XML (est devenu populaire à une date plus avancée)
• n'est pas mieux que le HTML eu égard à l'interaction utilisateur

ProWiki:CdmlPhilosophy