[Échange d'idées] Conception d'un site

Elzen · Le 24/10/2009, à 19:59

Quelques remarques récentes m'ont conduit à envisager que les solutions que j'ai choisies pour coder mon site (je parle de la nouvelle version en cours d'écriture, pas de l'ancienne qui est assez ratée sur certains points) me semblaient naturelles et évidentes à moi, mais que d'autres gens avec d'autres habitudes de codage pouvaient avoir des avis radicalement différents. (D'ailleurs, certains points n'étaient pas si évidents que ça au début, puisqu'on a dû me les indiquer)
Je crée donc ce sujet, non pas pour demander de l'aide du point de vue technique ou pour demander des conseils sur une préconception (a priori, je vais garder la mienne (à quelques retouches près, éventuellement), sauf si on d'indique des points vraiment problématiques), mais plutôt pour discuter entre concepteurs des solutions qui nous viennent à l'esprit, en espérant que ça serve à tout le monde.

Pour commencer, comme pour tout projet, il faut définir quelles sont les conditions de réalisation. Voici celles que je me suis fixé, sans ordre particulier de priorité :
* Le site doit être au moins en grande partie de type blog/forum : ajout d'articles et réponses possibles par les visiteurs, sans avoir besoin de privilèges d'administration.
* Le site doit pouvoir évoluer, la structure choisie ne doit pas être enfermante (possibilité d'ajouter des bouts qui s'intègrent bien tout en ne correspondent pas du tout au critère précédent)
* Le site doit être économique, autant que possible à la fois pour le serveur et pour les clients.
* Le site doit être accessible, c'est-à-dire respecter les normes et être pleinement compatible avec les différents navigateurs Libres.
* Le site doit être personnalisable : les utilisateurs doivent avoir la possibilité d'en modifier l'apparence.
* Les données présentes sur le site doivent pouvoir être protégées facilement (droit à l'oubli, tout ça) : les robots d'indexations ne doivent accéder qu'à la partie du contenu pour lequel ils sont désirés.
* Le site doit être simple d'administration, à la portée d'utilisateurs non-experts de l'informatique, et donc passer le plus possible par des outils d'utilisation courante.
* Les données présentes sur le site doivent pouvoir être archivables facilement, et les archives doivent pouvoir être consultables sans passer par un serveur web.
* Le site doit être transparent : dans la logique de partage des connaissances, les utilisateurs doivent avoir accès à tout ce qui n'est pas sensible (sources, etc).

Pour atteindre ces objectifs, j'ai donc fait les choix suivants (sans ordre précis également) :
* Uniquement par fichiers. Je n'utilise pas de base de données ni de mise en cache sur le serveur, qui nuieraient à la consultabilité des archives. De plus, cela permet de gérer toute l'administration du site avec uniquement deux outils : un navigateur de fichiers et un éditeur de texte (bon, plus éventuellement un navigateur web pour vérifier ce que ça donne).
* Les données sont présentes dans des fichiers séparés, à partir desquelles, à chaque modification (édit d'un post ou nouvelle réponse, par exemple) une ou plusieurs pages HTML seront générés pour éviter que le serveur ne doive relire tout à chaque fois. Les fichiers de configuration sont enregistrés dans un format type ".ini"/".desktop".
* Pas de réécriture d'URL : celle indiquée dans la barre d'adresse doit correspondre à l'emplacement des ressources demandées. Sauf dans un cas très précis : les utilisateurs enregistrés doivent avoir la possibilité de définir (via un formulaire simple) leurs propres feuilles de styles, qui se substitueront aux feuilles de styles par défaut.
* Une vérification rapide doit être faite avant l'accès à chaque ressources de l'accessibilité de cette dernière, une page d'erreur étant renvoyée si la ressource est protégée. Pour éviter l'indexation, un panneau d'accueil avec demande de connexion peut également être envoyé lors de cette vérification (la connexion est autorisée pour les visiteurs non-inscrits, mais cela doit être fait manuellement)
* Dans la partie blog/forum, un répertoire correspond soit à un sujet, soit à une liste de sujets. Chaque répertoire doit être indépendant, la génération des fichiers HTML dont j'ai parlé plus haut ne se fait que pour le répertoire concerné. Un même sujet peut être présent dans plusieurs sections différentes, grâce à des liens symboliques (ln -s ; ceci parce que le lien physique ne marche que pour les fichiers classiques).
* L'essentiel du site doit être présentable de manière statique (pour les navigateurs en mode texte, entre autres), mais traitements JavaScript peuvent être utilisés pour améliorer le confort d'utilisation. Des parties purement scriptées peuvent être envisager dans des cas précis (petits jeux, par exemple)

Qu'en pensez-vous ?

kouskous · Le 24/10/2009, à 20:25

Salut

* Le site doit être économique, autant que possible à la fois pour le serveur et pour les clients.

Par économique, tu entends quoi ? Economie de bande passante ? D'énergie ?

* Le site doit être accessible, c'est-à-dire respecter les normes et être pleinement compatible avec les différents navigateurs Libres.

Il ne doit pas être compatible avec les navigateurs propriétaires ? Pourquoi ?

* Le site doit être simple d'administration, à la portée d'utilisateurs non-experts de l'informatique, et donc passer le plus possible par des outils d'utilisation courante.

Par outils d'utilisation courante, tu penses à de outils pouvant être propriétaires ? Ne vaut-il mieux pas préférer des outils et des formats garantissant une certaine pérennité ?

* Uniquement par fichiers. Je n'utilise pas de base de données ni de mise en cache sur le serveur, qui nuieraient à la consultabilité des archives. De plus, cela permet de gérer toute l'administration du site avec uniquement deux outils : un navigateur de fichiers et un éditeur de texte (bon, plus éventuellement un navigateur web pour vérifier ce que ça donne).

C'est un choix, en effet ça permet d'accéder plus facilement aux données, mais est-ce plus optimisé qu'utiliser une base de donnée (et donc optimisation de la consommation) ?

* Les données sont présentes dans des fichiers séparés, à partir desquelles, à chaque modification (édit d'un post ou nouvelle réponse, par exemple) une ou plusieurs pages HTML seront générés pour éviter que le serveur ne doive relire tout à chaque fois. Les fichiers de configuration sont enregistrés dans un format type ".ini"/".desktop".

*.ini est made by Microsoft. Beuh

* Pas de réécriture d'URL : celle indiquée dans la barre d'adresse doit correspondre à l'emplacement des ressources demandées. Sauf dans un cas très précis : les utilisateurs enregistrés doivent avoir la possibilité de définir (via un formulaire simple) leurs propres feuilles de styles, qui se substitueront aux feuilles de styles par défaut.

La réécriture d'URL permet d'obtenir des URL lisibles et relativement compréhensibles, beaucoup plus agréable à accéder surtout depuis un site tiers. Pourquoi ne pas faire les deux ?

Dernière modification par kouskous (Le 24/10/2009, à 20:41)

HP · Le 24/10/2009, à 20:32

kouskous a écrit :

Les fichiers de configuration sont enregistrés dans un format type ".ini"/".desktop".
*.ini est made by Microsoft. Beuh

XML est un bien meilleur choix…

Elzen · Le 24/10/2009, à 20:59

Salut et merci pour ta réponse ^^

kouskous a écrit :

Par économique, tu entends quoi ? Economie de bande passante ? D'énergie ?

D'énergie, je suppose : je veux dire par là ne pas réeffectuer sans cesse des traitements inutiles. C'est l'un des gros problèmes de la version actuelle de mon site, il réouvre tous les fichiers pour générer une nouvelle page HTML à chaque fois que l'on demande à afficher une page. Il faut que la nouvelle version corrige ça.

kouskous a écrit :

Il ne doit pas être compatible avec les navigateurs propriétaires ? Pourquoi ?

Ce n'est pas qu'il ne doit pas, c'est plutôt que je n'ai pas l'intention d'accepter des licences que je considère comme trop privatives juste pour vérifier la compatibilité. Il faut que ce soit compatible avec le Libre, si ça l'est aussi avec le privatif, tant mieux, mais ce n'est pas prioritaire.

kouskous a écrit :

Par outils d'utilisation courante, tu penses à de outils pouvant être propriétaires ? Ne vaut-il mieux pas préférer des outils et des formats garantissant une certaine pérennité ?

Cette condition est déjà presque une annonce des choix que j'indique plus bas : par "outils d'utilisation courante", j'entends les logiciels que monsieur tout le monde utilise le plus souvent (le navigateur de fichier, notamment). Je veux dire par là qu'il ne faut pas qu'il y ait besoin de développer toute une appli spécifique (qu'elle soit graphique ou par formulaires web) pour faire la configuration, mais plutôt réinvestir ce qui existe déjà.
Au niveau des formats, j'utilise simplement du texte structuré.

kouskous a écrit :

C'est un choix, en effet ça permet d'accéder plus facilement aux données, mais est-ce plus optimisé qu'utiliser une base de donnée (et donc optimisation de la consommation) ?

Le niveau d'optimisation peut se discutter, en effet, mais l'utilisation d'une base de données aurait enfreint certaines de mes conditions : d'abord, qui dit base de données dit nécessité d'un outil supplémentaire pour gérer son contenu, tandis que toutes les interfaces que je connais permettent de manipuler les fichiers facilement.
Et puis surtout, une base de données nécessite un serveur de base de données (installé comme MySQL ou embarqué comme SQLite), avec probablement un traitement requis derrière (PHP ou autre), alors que je tiens à ce qu'une archive du site soit visitable sur n'importe quelle machine, quoi qu'il y soit installé (ça vient de ma configuration personnelle : je gère ma machine-serveur par SSH, mais je n'ai pas de serveur installé sur ma machine-utilisation, et je veux pouvoir visualiser ou préparer du contenu même quand je n'ai pas d'accès SSH).
En plus, tous les sites utilisant une base de données utilisent quand même des fichiers autours, donc dans l'absolu, je ne pense pas que la perte soit énorme si perte il y a.

kouskous a écrit :

*.ini est made by Microsoft. Beuh

D'où le fait que j'ai précisé également *.desktop qui est exactement la même structure, mais utilisée par les systèmes Libres (pour les lanceurs d'applications). J'ai choisi cette structure parce que je la trouve assez simple, et que PHP propose nativement une fonction de lecture de ces fichiers. Ceci dit, j'utilise les extensions ".info" et ".list" pour les fichiers de ce type.
Edit en réponse à HP : j'y ai pensé, mais le XML est également un peu plus lourd d'utilisation (beaucoup plus de caractères inutiles), et surtout moins simple à appréhender. Je rappelle que je veux que le site soit gérable par des non-experts, qui à mon humble avis préféreront comme moi en cas de besoin trouver la bonne ligne et modifier ce qu'il y a après le signe = que de chercher dans une succession de balises. Ceci dit, en ajoutant un petit éditeur simple, le XML pourrait également parfaitement remplir les conditions.

kouskous a écrit :

La réécriture d'URL permet d'obtenir des URL lisibles et relativement compréhensible, beaucoup plus agréable à accéder surtout depuis un site tiers. Pourquoi ne pas faire les deux ?

Parce que l'organisation spatiale que j'ai prévu me fournit directement des URL lisibles et compréhensibles. Par exemple, l'article du blog "Le Système Solaire" publiée dans le thème "Sciences" se trouvera dans un répertoire baptisé "Le_Systeme_Solaire" (par mesure de sécurité, j'ai un parsage auto des caractères un peu spéciaux), lui-même situé dans le répertoire "Sciences", lui-même situé dans la racine du blog, et sera donc quelque chose comme "/blog/Sciences/Le_Systeme_Solaire" sans réécriture aucune.

Ceci me fait penser qu'il y a un autre point que j'ai oublié de citer : le syndrôme du prisonnier (vous savez, « je ne suis pas un numéro, je suis un homme libre »). J'ai également fait le choix de n'utiliser pour identifiant que des chaînes de caractères (les noms des fichiers), rendant le repérage des sujets et des membres plus agréables que les indices chiffrés que se trainent les sites à base de données comme celui-ci.

Dernière modification par ArkSeth (Le 24/10/2009, à 21:03)

compte supprimé · Le 30/10/2009, à 00:56

Juste une remarque, la licence CC BY-NC-SA n'est pas une licence libre

Dernière modification par Lagierl (Le 09/07/2010, à 20:55)

HP · Le 30/10/2009, à 01:34

ArkSeth a écrit :

Edit en réponse à HP : j'y ai pensé, mais le XML est également un peu plus lourd d'utilisation (beaucoup plus de caractères inutiles), et surtout moins simple à appréhender. Je rappelle que je veux que le site soit gérable par des non-experts, qui à mon humble avis préféreront comme moi en cas de besoin trouver la bonne ligne et modifier ce qu'il y a après le signe = que de chercher dans une succession de balises. Ceci dit, en ajoutant un petit éditeur simple, le XML pourrait également parfaitement remplir les conditions.

Moins simple à appréhender pour des fichiers de conf, ça me fait doucement rigoler !
Je sais pas si tu as remarqué, mais les systèmes d'exploitation et autres applications "modernes" (par exemple Mac OS X, Fontconfig, Mozilla Firefox, etc) font un usage massif de XML. Bon, niveau perfomance, ça doit aussi se ressentir, parce que qu'on le veuille ou non, et n'importe comment qu'on s'y prenne, c'est quand même vachement plus facile à parser, même avec des expressions rationnelles un peu "stupides" que du plain text.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 24/10/2009, à 19:59

[Échange d'idées] Conception d'un site

#2 Le 24/10/2009, à 20:25

Re : [Échange d'idées] Conception d'un site

#3 Le 24/10/2009, à 20:32

Re : [Échange d'idées] Conception d'un site

#4 Le 24/10/2009, à 20:59

Re : [Échange d'idées] Conception d'un site

#5 Le 30/10/2009, à 00:56

Re : [Échange d'idées] Conception d'un site

#6 Le 30/10/2009, à 01:34

Re : [Échange d'idées] Conception d'un site

Pied de page des forums