Wikini

ToDoPublicationDeWikiNiVersion070

PagePrincipale :: DerniersChangements :: DerniersCommentaires :: ParametresUtilisateur :: Vous êtes ec2-18-210-23-15.compute-1.amazonaws.com

Attention on veillera à ne pas introduire trop de modifications car nous courrons alors le risque d'un délai de développement trop important.
-- CharlesNepote


Points faisant consensus


Points repoussés lors de la 0.5


InterfaceDAdministrationWikiNi, qui permettrait d'EmpecherLaCreationDunNouvelUtilisateur



Points repoussés lors de la 0.6


[bogue] Problème des puces

p.s.: Je n'ai pas mis de puce ici, mais WikiNi considère que je commence tout de même un nouvel élément de liste. Ça fait assez longtemps que je trouve cela assez gênant, peut-on considérer cela comme un bug ? Ça doit pas être terriblement difficile à corriger je pense…


Qui veut bien implémenter ça ? Ce n'est pas très compliqué et je n'ai pas trop le temps en ce moment... -- CharlesNepote



NePasChargerHeaderEnPremier

Exemples d'usages :
<link rel="alternate" type="application/rss+xml" title="rn7.net/b RSS" href="http://rn7.net/b/node/feed" />
<meta name="DC.Date" scheme="W3CDTF" content="2004-10-25" />
<meta name="DC.Creator" content="Charles Nepote" />
<meta name="author" content="Charles Nepote" />
<meta name="DC.Title" content="Sommaire de rn7.net" />
<meta name="DC.Language" scheme="RFC1766" content="fr" />
<meta name="geo.country" content="FR" />
<meta name="icbm" content="2.2933, 48.9152" />
<meta name="description" content="Site personnel de Charles Nepote" />
<meta name="keywords" content="carnet" />
<meta name="generator" content="Charles" />
<link href="mailto:charles@nepote.org" rev="made" />
<!-- Métadonnées relatives à openid -->
<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://charles.nepote.myopenid.com/" />
<meta http-equiv="X-XRDS-Location" content="http://charles.nepote.myopenid.com/xrds" />



Ok, je suis entièrement d'accord qu'il faut le faire. Et ça me démange depuis un moment ! Mais revenez sur terre, c'est un gros morceau. On n'aura jamais fini ça en 15 jours ! Repoussons le pour la 0.7. -- BenjE?



Intégration du nouveau style

Il s'agit de récupérer depuis l'ancien trunk (devs/various-until-2007-01-31) les développements pour le NouveauStyleWikini (voir aussi DiscussionsMergesWikiNi06?, paragraphe « Commits liés au nouveau style »)
Il a été convenu sur la mailing liste qu'il devrait s'agir du changement le plus important, car il est difficile de faire cela et d'autres modifications HTML simultanément. De plus chaque nouvelle fonctionnalité impliquant le code HTML retarde l'intégration du nouveau style et la rend plus difficile.

Namespaces


Améliorer la capacité à suivre les contributions sur l'ensemble du wiki.

Plus précisément : Permettre de choisir si le menu du haut contient des liens relatifs aux namespaces visités, ou des liens absolus au wiki complet.

Pour les pages globales, faciliter le choix entre modifier la page globale ou la page locale.


Faciliter la création des pages globales.


Liens


Permettre de corriger les erreurs de casse sur les liens.



Cache


Permettre à PageExist??() de répondre à la fois si la page existe et quelle est la bonne façon d'écrire sont tag.

Améliorer le cache d'existence des pages en utilisant des pré-calculs


Configuration

Voir les DiscussionsStockageDesDonneesDeConfiguration. Il reste des décisions à prendre notamment sur le choix des URI utilisées pour identifier les triplets.

Pour moi c'est OK pour qu'on implémente ça mais c'est toi (CharlesNepote) l'expert en triplets RDF ;-) -- DidierLoiseau

Points ne faisant pas consensus


Commenter un commentaire

Nouvelles idées à discuter


Normaliser l'API du noyau : expliquer quelque part quelle fonction doit être utilisée pour faire quoi ?


Visualiser les changements au moment de l'aperçu. En un clic, les changements apparaîtraient comme dans un diff. Comme ça on contrôlerait mieux les modifications éparses qu'on peut apporter à une grande page.


Fonctionnalités ne faisant pas consensus

[fonctionnalité classique] Upload de fichiers

Cette fonctionnalité est également souvent réclamée ; elle apporte une solution basique au besoin d'upload ; elle devient une fonctionnalité standard de nombreux moteurs.
Elle comporte cependant des problèmes en terme de sécurité : il faut clairement expliquer les impacts et proposer cette fonctionnalité comme option, qui plus est accessible par défaut aux seuls administrateurs.
Par ailleurs, je ne suis pas convaincu de l'ergonomie et du code des implémentations actuelles : il faut des formulaires simples.

[fonctionnalité innovante] Sortie au format S5 : DiscussionsHandlerS5?

A voir. Pas d'impact sur le noyau mais il y a des impacts sur l'arborescence et sur la CSS.
Si j'ai le temps, je vous fait des propositions, sinon on laisse tomber. -- CharlesNepote



[fonctionnalité innovante] Actions de la CategorieMicroformats?

A voir. Manque encore de maturité ?
Si j'ai le temps, je vous fait des propositions, sinon on laisse tomber. -- CharlesNepote



[fonctionnalité classique] Action UserLogin??

?

Discussion sur l'externalisation de la gestion de la base de données

Les fonctions de manipulation de la base de données sont actuellement implémentées au cœur du noyau de WikiNi. Cette fonctionnalité viserait à externaliser ce code, permettant ainsi de se connecter avec d'autres DBMS que MySQL et d'obtenir un code plus propre. D'autres possibilités pourraient également être offertes telles que les requêtes préparées (voir à ce sujet la section consacrée dans la documentation php:pdo)


Je trouve dommage de perdre du temps sur ce genre de discussion de tringlerie alors que nous avons mieux à faire sur le terrains des vrais fonctionnalités utilisateur. -- CharlesNepote



Vos explications ne me convainquent pas : l'argument de la simplicité ne vaut que pour les programmeurs expérimentés car l'usage d'une classe supplémentaire rend le développement plus difficile pour les programmeurs débutants (qui apprécient d'ailleurs beaucoup WikiNi). Les demandes du support d'autres bases sont absolument marginales. Le public principal de WikiNi, plutôt des individus et des associations qui ont des hébergements LAMP mutualisés, n'a pas besoin du support d'autres bases. Il n'y a pas d'apport fonctionnel direct au support d'autres bases.
Je ne vois que deux raisons, assez marginales, pouvant éventuellement pousser à ce développement :


Je ne conçois pas l'externalisation de la base de données sans une vraie fonctionnalité supplémentaire.
-- CharlesNepote

Les gars, vous pouvez signer plus clairement svp ? On a du mal à voir qui a dit quoi dans votre discussion. -- BenjE?

La question est délicate parce qu'effectivement, ça va pas nous apporter grand chose de gérer plusieurs bases de données. La classe wiki est un peu trop grosse, certes, mais il ne faut pas confondre les objectifs. Gérer d'autres SGBDR, c'est pas la même chose que remettre à plat la conception objet de Wikini. Ce sont deux objectifs distincts. Moi, je dirais "pourquoi pas" pour les deux. Mais avons-nous vraiment le temps pour nous amuser à faire ça ? N'y a-t-il pas plus urgent ? -- BenjE?


Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]