Auteur Sujet: Créer un nouveau moteur de forum pour remplacer SMF (aujourd'hui utilisé ici) (Lu 14347 fois)

corrector · « **Réponse #48 le:** 06 mai 2017 à 22:59:03 »

Il faudrait déjà avoir un tableau des features souhaitées et des différences entre les moteurs...

Marco POLO · « **Réponse #49 le:** 07 mai 2017 à 00:38:53 »

Citation de: miky01 le 06 mai 2017 à 08:45:28

...Pour ma part on change pas qques chose qui remplit 99% des besoins, et fiable...

+1

corrector · « **Réponse #50 le:** 07 mai 2017 à 05:55:27 »

Et donc rester bloqué indéfiniment avec un logiciel non maintenu?

corrector · « **Réponse #51 le:** 07 mai 2017 à 08:22:21 »

Il se passe quoi?

vivien · « **Réponse #52 le:** 07 mai 2017 à 08:28:27 »

Je précise juste que SMF est maintenu et reçois régulièrement des mises à jour de sécurité.

La mise à jour de fonctionnalités sont elles aussi développées, mais mettent du temps à sortir. Il y a toujours plusieurs mois de tests.

corrector · « **Réponse #53 le:** 07 mai 2017 à 08:38:41 »

Pourquoi le topic a été bloqué?

TroniQ89 · « **Réponse #54 le:** 08 mai 2017 à 13:25:03 »

Citation de: corrector le 07 mai 2017 à 08:38:41

Pourquoi le topic a été bloqué?

Il a été bloqué? je n''ai pas vu.

corrector · « **Réponse #55 le:** 08 mai 2017 à 23:33:31 »

Assez brièvement.

kgersen · « **Réponse #56 le:** 10 mai 2017 à 22:05:10 »

Citation de: Marin le 05 mai 2017 à 14:24:54

En tant qu'utilisateur régulier d'un langage de quatre ans plus vieux (Python) je me sens offensé par ta remarque. Je te demanderais donc de bien vouloir spécifier ce qui entrave en pratique l'utilisation de technologies répondant à la demande une fois maîtrisées et toujours activement maintenues.

Je ne met pas Python sur le même plan que jquery & php. C'est un langage de programmation. Meme si php est aussi un langage c'est avant tout un framework de scripting, coté serveur, fortement orienté pré-processing, bref une 'facon ancienne' de faire du web dynamique.

Rien n'entrave l'utilisation de ces technologies si on a le temps et l'énergie pour ça... c'est juste pas ce qu'il faut si on cherche l'efficacité et si on veut profiter des nombreux progrès effectués ces dernières années aussi bien coté backend/serveur que coté frontend/client.
Un peu comme rien n'entrave un écrivain d'utiliser Notepad pour écrire un roman au lieu d'utiliser Word...

Perso si je devais faire un remplaçant a SMF soit je parsirai de rien avec une backend purement 'data' bien spécifié et interfacer via GraphQL avec un frontend utilisant React (ou du moins son principe dont les bienfaits ont été démontrés) soit je parsirai d'un projet open-source comme Discourse.org pour le 'modifier' (mod/theme) pour ressembler a SMF (nettement moins de boulot à faire a mon avis).

Apres j'ai aussi une dent contre Python mais pour d'autres aspects notamment son coté interprété, son manque de typage statique et sa sémantique liée a l'indentation/mise en forme. J'ai connu Python a ses débuts quand c’était qu'un langage de scripting utilisé pour faire du scripting. Qu'on s'en serve pour ça encore de nos jours ok mais quand je vois des projets complexes entiers fait entièrement en Python cela me fait frémir...

d'autant plus que cela m'oblige souvent a l'utiliser aussi...

Marin · « **Réponse #57 le:** 10 mai 2017 à 22:57:56 »

Citation de: kgersen le 10 mai 2017 à 22:05:10

Je ne met pas Python sur le même plan que jquery & php. C'est un langage de programmation. Meme si php est aussi un langage c'est avant tout un framework de scripting, coté serveur, fortement orienté pré-processing, bref une 'facon ancienne' de faire du web dynamique.

Tu veux dire que c'est gênant pour faire de l'asynchrone, du polling proprement et ce genre de choses ? PHP comme tout ce qui est haut niveau et maintenu aujourd'hui dispose des diverses fonctionnalités orientées objet et autres paradigmes qui seront couramment voulues pour modulariser un projet, même algorithmiquement et structurellement complexe.

Citation de: kgersen le 10 mai 2017 à 22:05:10

Apres j'ai aussi une dent contre Python mais pour d'autres aspects notamment son coté interprété, son manque de typage statique et sa sémantique liée a l'indentation/mise en forme.

L'interprétation du code est une variable de compromis comme une autre, qui limite intrinsèquement il est vrai certaines applications (et pour lesquels des solutions de contournement de plus en plus incroyables viennent à être imaginées, du même temps que les capacités techniques du matériel évoluent). Les applications web à forte charge ne s'en soucient à peu près plus depuis la disparition du CGI cependant.

Le manque de typage statique, c'est un problème de gens qui savent mal documenter leurs interfaces quand ils sortent du domaine du mono-fichier.

L'indentation n'est pas un problème. Le vrai problème pour moi ce serait de comprendre les gens qui indentent irrégulièrement, veulent indenter irrégulièrement leur code ou viennent à indenter irrégulièrement leur code plus que par erreur des plus occasionnelles. Pourquoi ? Un éditeur de code qui ne soit pas nano s'en charge, comme pour l'écrivain avec son Bloc-Notes il peut y avoir un désir d'utiliser nano mais je le comprends encore moins.

Citation de: kgersen le 10 mai 2017 à 22:05:10

J'ai connu Python a ses débuts quand c’était qu'un langage de scripting utilisé pour faire du scripting. Qu'on s'en serve pour ça encore de nos jours ok mais quand je vois des projets complexes entiers fait entièrement en Python cela me fait frémir...

Ça c'est le point intéressant à développer plus. Quels sont les aspects qui portent défaut à cet usage ?

corrector · « **Réponse #58 le:** 10 mai 2017 à 23:35:22 »

Quels sont les langages/outils/framework qui protègent complètement contre les injections SQL/XSS/...?

Marin · « **Réponse #59 le:** 11 mai 2017 à 07:49:12 »

Citation de: corrector le 10 mai 2017 à 23:35:22

Quels sont les langages/outils/framework qui protègent complètement contre les injections SQL/XSS/...?

Pour les frameworks orientés web, je dirais à peu qu'à près tous ceux qui incluent une forme de templating ou d'une autre pour le rendu web, ou un ORM pour les requêtes, protègent dans un usage normal, c'est un des buts fondamentaux de ce genre d'outils et j'en vois peu qui dérogent sauf pour ceux dans lesquels ces fonctions ne sont pas dans la scope fondamentale.

Pour ceux qui protègent complètement contre les XSS en revanche, je dirais qu'il n'y en a sûrement aucun car soit envoyer un contenu avec le mauvais mimetype, soit contourner explicitement la protection pour la sortie du contenu est souvent possible. Et un framework est généralement soit serveur, soit client, il y a beaucoup de vulnérabilités complexes dans les produits Google et autres qui tirent parti de choses implèmentées en Javascript ou Flash client.