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

0 Membres et 1 Invité sur ce sujet

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

Marco POLO

  • Abonné Free fibre
  • *
  • Messages: 2 131
  • FTTH 1 Gb/s sur Paris (75)
...Pour ma part on change pas qques chose qui remplit 99% des besoins, et fiable...
+1 

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

  • Invité
Il se passe quoi?

vivien

  • Administrateur
  • *
  • Messages: 48 042
    • Twitter LaFibre.info
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.

  • Invité
Pourquoi le topic a été bloqué?

TroniQ89

  • @TroniQ89
  • Abonné Free adsl
  • *
  • Messages: 743
Pourquoi le topic a été bloqué?

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

  • Invité
Assez brièvement.

kgersen

  • Modérateur
  • Abonné Orange Fibre
  • *
  • Messages: 9 230
  • Paris (75)
Créer un nouveau moteur de forum
« Réponse #56 le: 10 mai 2017 à 22:05:10 »
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... :P d'autant plus que cela m'oblige souvent a l'utiliser aussi...

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 795
  • 73
Créer un nouveau moteur de forum
« Réponse #57 le: 10 mai 2017 à 22:57:56 »
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.

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.

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... :P

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

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

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 795
  • 73
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.
« Modifié: 11 mai 2017 à 08:11:08 par Marin »