La version 2.8 apporte un grand nombre d'améliorations et de corrections parmi lesquelles :
- une bien plus grande vitesse de rendu des pages (deux fois plus rapide que la version précédente) ;
- une consommation mémoire très fortement réduite (jusqu'à quatre fois moins de mémoire utilisée) ;
- une compatibilité accrue avec les différentes implémentations de Smalltalk (Squeak, Visual Works et GemStone) ;
- beaucoup plus de documentation, de tests unitaires et un site web refait à neuf.
Un guide de migration a aussi été réalisé pour aider les développeurs à passer d'une version à une autre.
![[en]](../images/en.png)
Seaside (1047 hits)-
L'annonce de Seaside 2.8 (151 hits)
-
Quelques screenshots (1109 hits)
-
Le guide de migration (141 hits)
![[fr]](../images/fr.png)
Wiki francophone (481 hits)-
DLFP : annonce de la version 2.7 précédente (126 hits)
> Lire la dépêche (38 commentaires, moyenne: 2,9).
Vous avez demandé le commentaire #878288.
Run by 
Cette page a été générée par Templeet en 0.0605s (dont 0.0057 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
[+] Question provoc
Est ce que le "marché" des frameworks Web n'est pas déjà ultra saturé ?
Franchement, à quoi ca sert toutes ces micros communautés qui réinventent la roue et proposent des frameworks pour leur petit langage préféré. C'est du fétichisme.
Entre les frameworks Java, PHP et ses milliers de frameworks et les Ruby On Rail et Cie, ça devient vraiment ridicule.
On dirait que chaque geek qui se lance dans la conception d'une appli Web développe son framework perso.
C'est comme pour les window manager sous linux. La foire aux geeks désoeuvrés. Et c'est contre productif. C'est autant d'énergie perdue à diviser les efforts plutôt que d'essayer d'améliorer l'existant.
C'est triste.
[^]Re: Question provoc
C'est justement là que c'est différent.
Seaside n'offre pas du tout la même vision du web qu'un autre framework. Il abstrait vraiment HTTP, Javascript et consort. Même la notion d'URL est limite inutile.
De l'autre coté c'est de la diversité que vient l'innovation. Si on utilisait tous les même outils, le même environnement et OS, le monde serait bien triste...
[^]Re: Question provoc
Et monopolistique…Comment marchent le « moinssage » et le « plussage » ?
[^]Re: Question provoc
> Seaside n'offre pas du tout la même vision du web qu'un autre
> framework. Il abstrait vraiment HTTP, Javascript et consort. Même la
> notion d'URL est limite inutile.
Ce n'est pas le premier et je trouve toujours ça très nul.
On manipule du Web. Les liens et les URL sont la composante de base. La masquer c'est coder autre chose que du Web et la première chose à imaginer pour faire des erreurs basiques sur un site Web (genre des URL dégueu, des perf pourries, des pages non bookmarkables, etc.)
Un framework c'est un cadre de travail, ça ne doit pas être là pour oublier ce qu'on manipule.
A la limite je comprend quand le but c'est *réellement* de faire un code qui fonctionne directement sur plusieurs transports et pas que sur le Web, mais j'ai rarement vu quelque chose de vraiment fonctionnel de ce côté là (sans avoir à refaire toute la vue et plein de code en double)
[^]Re: Question provoc
Si je ne me trompe pas (corrigez moi sinon) les pages générés par seaside sont bookmarkables par exemple.
Pour ce qui est des url dégueu ou non, ben je dirais plutôt que ça dépend ce que l'on code. Si pour un site de "contenu" (blog pour prendre un exemple bateau) c'est intéressant d'avoir une belle url, dès qu'on s'oriente vers des applications web, la beauté de l'url on s'en fout un peu (entendre par là que jamais on mettera un bookmark, jamais on tappera une url). De plus, même si les urls sont parfois "belles" (y compris pour des sites des contenu) il est bien rare de s'en servir.
Le truc à mon avis c'est que seaside est là pour faire un peu plus qu'un site Web. Et le fait d'avoir des urls 'illisibles' ou non je vois pas trop ce que ça change sur les perfs. Pour moi ce serait plutôt le contraire, pour avoir des belles urls on va plutôt faire des choses verbeuse, en utilisant des strings, là où un identifiant numérique serait plus efficace.
J'avais lu un article il y a quelques temps sur seaside (dans un glmf) et le côté composant est assez attirant. (Ils expliquaient par ailleurs l'histoire des urls, mais je l'ai pas sous la main...)
[^]Re: Question provoc
Elles sont bookmarkables si tu le spécifie dans ton code, pas par défaut.
Je crois que Seaside est adapté pour faire des applications web où il n'y a pas besoin d'avoir d'URLs à conserver. Pour un site web, Seaside est peut-être moins intéressant.
Mais bon la question de savoir si les URLs sont importantes ou pas dans un framework web, cela peut veut devenir un troll ;-)
L'intérêt de Seaside, c'est que tu code une application web comme tu coderais une application classique, tu te soucie pas des tracas liés au protocole HTTP.
[^]Re: Question provoc
En fait, si tu regardes les urls de la news, elles pointent presque toutes vers seaside.st qui est un site web écrit en Seaside (en fait, c'est fait avec le CMS Pier qui est implémenté au dessus de Seaside). Donc, les urls sont bien bookmarkables.
Damien Cassou
[^]Re: Question provoc
C'est justement cette diversité qui donne envie aux gens d'expérimenter de nouvelles idées et d'innover; ce qui donne des références reprises par d'autres projets avant de repartir dans l'innovation et ainsi de suite... enfin, c'est le libre quoi.
[^]Re: Question provoc
Il faut voir aussi que Seaside (sauf erreur) existait avant Ruby on Rails (2002 environ pour Seaside, 2004 pour Rails) et avant beaucoup d'autres frameworks web.
Comme d'autres l'ont dit, l'approche est complètement différente et apprendre à utiliser Seaside permet de mieux se rendre compte des limitations des autres frameworks.
Damien Cassou
[^]Re: Question provoc
Je crois que la première version de Seaside a été codé en Ruby par Avi Bryant son concepteur. Puis il l'a réécrit en Smalltalk, car il n'était pas satisfait ...