Présentation
21 ans. Etudiant en dernière année dans une école d'ingénieur.
Compétences pour ce Wiki
Développement PHP
Design & Interfaces CSS
Suggestions personnelles concernant l'amélioration du Wiki
Sommaire des pages
Un moyen de créer un sommaire automatique :
ActionSommaire
Encodage des adresses emails
Pour limiter les risques de spam :
EncodageDesEmails
Commentaires de code
Relire les fichiers sources existants est une vrai galère. Même si la structure générale est compréhensible et claire, très peu de commentaires, des tas d'expressions régulières etc.
Ce serait une très très bonne chose que les auteurs des fichiers prennent un instant, un jour ou l'autre, pour ajouter des commentaires concernant l'interet de chaque fichier, et éventuellement les grandes étapes.
Customization Wiki
Une séparation complète du contenu du wiki et de l'interface/présentation/menus permettrait tout d'abord de faire évoluer le wiki avec les nouvelles versions de
WikiNi en gardant un design et une présentation identiques, d'autre part de créer une communauté plus orientée graphique qui pourrait proposer des thèmes, présentations originales, et travailler éventuellement plus intuitivement sur l'ergonomie.
Solution proposée
- Faire simple, avant tout. Pas de moteur de template. Mais séparation dans les fichiers sources header, footer, des actions. Dans un dossier themes/nomDuTheme, par exemple. Et regrouper à l'intérieur les fichiers css et tous ceux qui concernent la mise en page. Dans le fichier de configuration, permettre le choix du thème.
- Je me suis également toujours demandé ce que faisait header et footer dans le répertoire /actions. Je pense qu'on doit gagner un peu de code en les laissant là mais je suis tout de même pour une séparation meilleure (comme celle que tu proposes avec les CSS). En revanche, je ne vois pas trop l'intérêt d'une variable "thème" puisque cette notion est possible avec les FeuillesDeStyleMultiples (cf. le BacAStyle). -- CharlesNepote
- Les feuilles de styles multiples apportent un + au niveau ludique du site. Mais c'est une fonctionnalité qui n'a pas trop de sens pour des sites sérieux, qui ont une charte graphique, et qui ne veulent pas spécialement que leur site puisse être vu de 5 façons différentes. D'autant que j'ai ajouté pour un style personnel de nombreuses balises (pour mon sommaire automatique par exemple), que le style par défaut ne gère pas. En clair, selon moi (ça reste un détail), les styles switchers sont un + à proposer éventuellement, mais pas vraiment une solution sur laquelle baser l'usage des thèmes. Par la suite, il serait très bien de pouvoir mettre dans cette variable une liste de plusieurs thèmes "default,orange,blue" et de proposer le style switcher sur ces trois thèmes.
- Je vais essayer de séparer le contenu du design et interface. --JeremieCook
- Ajouter la possibilité de mettre un menu. J'ai ajouté un menu directement dans le header.php, avec des liens vers les pages concernées. Ces pages sont logiquement considérées comme orphelines, puisque mes liens ne sont pas interprétés par le wiki. Il faudrait trouver une solution intelligente pour la gestion de ces interfaces.
- Oui, il faudrait... il y a déjà quelques propositions qui trainent... il faudrait commencer par les synthétiser. -- CharlesNepote
- En profiter pour améliorer les détails concernant le code source des pages. Mettre le javascript dans un fichier séparé, ainsi que tous les informations qui concernent le design.
- "Les détails concernant le code source des pages" ? Qu'entends-tu par là ? Petit à petit j'essaye de faire en sorte d'avoir un code généré plus lisible. Il se peut qu'il y ai encore des incohérences. N'hésite pas à les signaler. Pour le Javascript dans un fichier séparé je ne suis pas hyper chaud parce que cela risque d'être plus coûteux en termes de performance (au-dessous d'une certaine taille, il vaut mieux le mettre dans le corps de la page). En outre, nous avions plus ou moins décidé de le supprimer étant donné que les espaces remplacent les tabulations pour l'indentation (depuis la version 0.1.2 je crois)... -- CharlesNepote
- Concernant le javascript, surtout voyant le nombre d'expressions régulières utilisées dans le code, je doute que ça puisse être réellement associé à une grande baisse de performances. Dans l'absolu, l'idée du xhtml/css est de séparer totalement le contenu de la page (sémantique) de tout ce qui concerne le design. Dans cette logique, il veut mieux mettre le javascript dans une page à part, ainsi que quelques styles qui restent dans la page. C'était une petite suggestion, c'était déjà pas mal comme ça. Voila un bon article sur le sujet. Ceci dit, pour l'intégration d'un menu (voir les Contributions) créé à partir de tableaux, c'est plus problématique. --JeremieCook
URL Signifiantes
Pourquoi ne pas renommer la première page wakka.php en index.php ?
Ça permettrait d'avoir des url comme :
http://www.wikini.net/?wiki=AFaireMoinsDe10Minutes
c'est déjà plus lisible et facile à retenir.
Le top, ce serait même de virer la variable wiki :
http://www.wikini.net/?AFaireMoinsDe10Minutes
En récupérant simplement l'adresse complète en PHP (système utilisé sur dotclear)
--
JeremieCook
Pourquoi pas. Note qu'il existe déjà la
ReecritureDUrl qui le permet déjà sur certains serveur (Apache, autres (?)). Dans tous les cas, il faut bien évaluer les impacts sur le code actuel (ça ne doit pas être trivial). Il me semble qu'il y a certains avantages à conserver le couple index.php/wakka.php tel qu'il est :
- potentialité d'intégrer le wiki dans le même répertoire qu'une autre application
- (autres ? je n'en vois pas mais il me semble qu'il y en avait d'autres...)
Pour ma part, je pense que cette modification n'a rien d'urgent au regard des autres projets et attentes (documentation, administration, anti-spam, etc.). Mais si tu proposes une solution simple et efficace, je ne vois pas d'opposition.
--
CharlesNepote
- Oui c'est tout à fait dans la logique de ReecritureDUrl que je proposais de renommer les adresses. Pour tous les hebergeurs gratuits, qui sont rares à proposer cette fonctionnalité. D'autant que cette réécriture posais des problèmes d'accès au CSS (du moins, ça n'a pas été évident quand j'ai essayé de l'appliquer sur mon serveur apache). L'avantage de cette méthode, malgré le ? et d'être utilisable partout et de ne demander aucune ressource supplémentaire. Concernant l'impact sur le code, ça a été effectivement moins facile que ce que j'imaginais, apparemment, ces longues adresses et le fichier wakka.php ont du faire l'objet d'un choix (donc surement des raisons valables). Ça n'a effectivement rien d'urgent.
- Concernant l'anti-spam, c'est déjà un ou presque ... --JeremieCook