La version 3 va également apporter un grand plus au niveau de la sécurité en échappant par défaut toutes les chaînes de caractères pouvant être sujettes à une attaque XSS. La version 2.3.6 devait permettre de tester ce comportement en installant le greffon Rails XSS. Mais, certains commits n'ont pas été backportés depuis Rails3, rendant ainsi cette protection non seulement inefficace mais aussi source de plantages. Heureusement, la version 2.3.7 est sortie juste après pour réparer ça. Au final, si vous êtes un utilisateur de Rails, vous êtes encouragés à sauter la version 2.3.6 et à passer directement à la version 2.3.7.
Mise à jour : Rails 2.3.8 vient de sortir pour corriger un problème lorsque l'on n'utilise pas le greffon Rails XSS. C'est donc vers cette version qu'il faut migrer.
Et si vous préférez la programmation fonctionnelle, sachez que le développement web vous est aussi ouvert. Par exemple, Snap est un framework web en Haskell sous licence MIT. Snap se décompose en trois parties :
- Une bibliothèque serveur HTTP très rapide, qui s'appuie sur la boucle événementielle de la libev ;
- Une monade particulièrement bien adaptée au développement web ;
- Un moteur de templating XML qui permet de générer entre autres du HTML.
Enfin, Lamson est un framework de développement en Python sous la double licence BSD et GPL. Sa particularité est d'être un framework pour les mails. Il propose une approche similaire à celle de Django ou Ruby on Rails, mais pour développer des applications qui gèrent des mails. Vous avez ainsi la possibilité de router des mails entrants, d'utiliser le modèle MVC, d'utiliser des données en provenance de différentes bases de données (relationnelles ou non), d'utiliser un ORM si vous le souhaitez, ou encore d'écrire des tests unitaires. Bref, Lamson permet enfin d'écrire facilement des applications qui gèrent des mails, que ce soient des filtres anti-spams, des mailing-listes, ou des applications très spécifiques.
Aller plus loin
- Ruby on Rails 2.3.6 (8 clics)
- Ruby on Rails 2.3.7 (5 clics)
- Plugin Rails XSS (2 clics)
- Snap framework (27 clics)
- Lamson Project (8 clics)
- Lamson 1.0 (6 clics)
# Parallèle Snap / Ocsigen
Posté par Maclag . Évalué à 3.
Haskell et Ocaml ont un certain nombre de points communs au niveau langages.
On a bien un environnement Ocaml avec un serveur web, un framework web, etc. (Ocsigen)
Et je découvre qu'on a à peu près la même chose sous Haskell.
Est-ce un choix historique de l'une des deux équipes (le syndrôme "moi aussi je peux!"), une pure coïncidence, ou une sorte d'évolution logique du framework seul offert grâce aux langages?
[^] # Re: Parallèle Snap / Ocsigen
Posté par Elfir3 . Évalué à 4.
Quand je vois ce qu'on trouve sur la toile, à mon avis il doit y avoir un rapport avec ça...
http://www.webtoolkit.eu/wt
http://code.google.com/p/frothkit/
http://g-framework.org/
et il y en a qui ont pas froid aux yeux... http://weblocks.viridian-project.de/
Allez, demain j'écris mon framework web en whitespace ! Des amateurs ?
[^] # Re: Parallèle Snap / Ocsigen
Posté par Victor . Évalué à 2.
http://liftweb.net/
[^] # Re: Parallèle Snap / Ocsigen
Posté par Maclag . Évalué à 6.
Dans la description de Lift, un peu plus bas que la courte description de la révolution, il y a écrit qu'il reprend le meilleur des autres frameworks...
En même temps, ça parait logique: tous les développeurs semblent avoir un langage préféré, avec une logique particulière propre. Du coup, on finit toujours par trouver des développeurs convaincus que "leur" langage est le meilleur pour la programmation web!
Ceci dit, qui s'en plaindra?
M'en vais me faire un framework web codé en assembleur qui va déchirer sa race à sa mère!!
----------------> [ ]
# Lamson
Posté par Larry Cow . Évalué à 4.
[^] # Re: Lamson
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
http://smtpd.develooper.com/
C'est un serveur SMTP modulaire en Perl. Je ne sais pas ce qui les rapproche et/ou les éloigne. Si quelqu'un connaît les deux, ce serait intéressant d'avoir un avis la dessus.
# Pourquoi ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Ha ? Et précisément en quoi est-elle particulièrement adaptée ?
Parce qu'une monade, c'est rien d'autre qu'un design-pattern avec quelques contraintes...
>> Snap est encore très jeune, mais ses performances sont déjà impressionnantes : plus rapide qu'apache !
Ca aussi, c'est impressionnant et très rapide : http://john.freml.in/teepeedee2-c10k avec du bon Common Lisp dedans.
Et comme c'est des S-Expressions, on peut generer le code HTML/XML a partir du code lisp lui meme...
[^] # Re: Pourquoi ?
Posté par Victor . Évalué à 2.
Mais il faut quand même y mettre quelque chose dans ce design-pattern :)
Et c'est ce quelque chose qui est particulièrement bien adaptée au développement web
Je pense qu'elle permet d'abstraire et « purifier » les effets de bords que tu vas faire sur le résultat du traitement de la requête histoire que ce soit sûr et élégant… (souvent on fait ce genre de trucs avec les monades donc je ne risque pas trop de me tromper :)
[^] # Re: Pourquoi ?
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Oui, enfin, c'est pas lié au concept de monade lui-même.
Il serait bien plus sensé d'écrire « des structures de données et algorithmes adaptés au développement web avec un langage fonctionnel. »
Par exemple, du « message passing » au lieu de plein d'effets de bords, c'est super agréable à utiliser avec un tas de langages fonctionnels.
>> Je pense qu'elle permet d'abstraire et « purifier » les effets de bords que tu vas faire sur le résultat du traitement de la requête histoire que ce soit sûr et élégant…
Abstraire, oui. C'est d'ailleurs la force des langages fonctionnels de permettre un raisonnement de haut niveau.
Purifier, non. Ça ne purifie rien une monade. Ça dit que ce qui est dedans ne « déborde » pas, ce qui est complétement différent. Ensuite, ce n'est pas parce que la monade IO utilisée pour justifier les effets de bords est nécessaire à tout programme non trivialement évaluable (car si on ne fait pas d'IO, on a pas besoin d'évaluer le programme !) que toutes les monades servent à ça !
On fait souvent des continuations avec des monades, du passage implicite d'arguments, du backtracking, et même des listes toutes connes sans aucun effet de bord.
Bon, d'après le code, c'est une combinaison d'environnements (passage implicite d'argements), de traitement des données (ou de son échec) et d'effets de bords. Une belle abstraction, en effet.
Mais une monade, c'est aussi *nécessairement* la vérification de lois (comme l'associativité). Et peu sont ceux qui prouvent que ces lois sont vérifiées quand ils créent (ou croient créer) une monade. On peut tout à fait en Haskell écrire un programme avec un truc qui ressemble à une monade, qui utilise la formule magique "instance Monad" et qui n'est pas une monade.
Bref, encore une victoire des langages fonctionnels (pour l'élégance du code) et du buzz (pour le côté « oh ! c'est grâce à une monade [lien vers un article imbitable pour le commun des mortels sur les catégories pour donner un semblant d'autorité à la déclamation] que c'est cool. »)
[^] # Re: Pourquoi ?
Posté par Victor . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.