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. Seaside inclut :
- Une génération du code HTML à partir de code Smalltalk. Le codage HTML à la main est souvent rébarbatif : toujours les mêmes répétitions de listes, de liens, de formes et de tableaux qui apparaissent page après page. Seaside a une API complète pour générer du code HTML qui vous permet d'abstraire ces répétitions en méthodes correspondantes plutôt que de copier-coller toujours les mêmes séquences de balises. Ceci permet aussi de garantir que le code HTML qui va être généré est bien compatible XHTML 1.0 strict.
- Une gestion des requêtes de type callback. Ceci permet de mettre la définition d'un lien ou d'un champ de formulaire juste à côté du code qui va être exécuté pour gérer ce lien ou ce champ. Plus besoin alors de penser en terme d'identifiant et de décodage d'URLs.
- Une architecture de composants. Un composant est décrit par une classe. Chaque composant est capable de rendre du code HTML (grâce à une API Smalltalk), d'afficher d'autres composants ou d'appeler un second composant qui va alors remplacer le premier. Ceci vous permet de penser à votre application comme un ensemble de composants avec chacun un rôle bien défini. Comme chaque composant est indépendant, il est possible de les réutiliser dans plusieurs applications ; Seaside en fournit même quelques uns.
- Une gestion des sessions. Seaside permet la modélisation du flux entier de l'application dans une même méthode. Ceci permet d'écrire une application web comme si vous écriviez une application non web.
- Seaside possède aussi un bon support de CSS et de Javascript, des outils de développement accessibles depuis le navigateur, un vrai support du débogage, un système de configuration et de préférences et bien plus.
Aller plus loin
- Seaside (4 clics)
- L'annonce de Seaside 2.8 (1 clic)
- Quelques screenshots (6 clics)
- Le guide de migration (2 clics)
- Wiki francophone (8 clics)
- DLFP : annonce de la version 2.7 précédente (1 clic)
# Smalltalk
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: Smalltalk
Posté par Damien Cassou . Évalué à 7.
[^] # Re: Smalltalk
Posté par reno . Évalué à 1.
[^] # Re: Smalltalk
Posté par Thomas . Évalué à 4.
Je trouve la syntaxe plus simple et plus flexible. Tu peux rajouter facilement des structures de contrôle comme tu le ferais en CL avec ses bonnes vieilles macros.
Les implémentations sont généralement plus matures, notamment au niveau du garbage collector (généralement quand quelqu'un râle contre les GC c'est qu'il n'en a pas utilisé de bon.) Les implémentations compilent en bytecode, tu peux sauvegarder ta VM en l'état (càd avec toutes ses libs chargées, pour un démarrage plus rapide)... Bref, pas mal d'avantages.
Essaie une fois et tu verras. Quand j'en faisais un peu (avant de retourner à CL) j'avais testé Squeak (c'est louche au début à cause de l'interface) et Cincom Smalltalk (pas libre mais gratuit et c'est un bon truc). Tu remarqueras vite aussi la différence entre le mode de développement en Ruby et celui en Smalltalk.
En Smalltalk, tout comme en CL ou Erlang, tu développes ton code vraiment de manière incrémentale. En Smalltalk, tu développes en "bottom-up "et pas "top-down". Càd que tu commences par coder de petites fonctions de bas niveau, tu t'amuses un peu avec pour vérifier que tout marche, puis tu les combines dans des fonctions plus grandes, jusqu'à arriver à ce que tu veux (je dis fonctions mais en Smalltalk on parleras plus d'objets et de méthodes... mon habitude du CL qui ressort ;-) )
PS: j'ai pas l'url pour Cincom Smalltalk, mais ça se trouve facilement.
[^] # Re: Smalltalk
Posté par Damien Cassou . Évalué à 3.
[^] # Re: Smalltalk
Posté par Larry Cow . Évalué à 3.
[^] # Re: Smalltalk
Posté par Victor . Évalué à 2.
De toutes manières, Linux est inspiré d'Unix, alors je ne suis pas sur que Unix apporte beaucoup dans ce cas.
Ce qui est plutôt vrai ... :)
[^] # Re: Smalltalk
Posté par reno . Évalué à 0.
Bin si, il est moins cher.
[^] # Re: Smalltalk
Posté par Florent Peyraud (site web personnel) . Évalué à 2.
# Question provoc
Posté par cdvddt . Évalué à -2.
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
Posté par tulipemoutarde . Évalué à 10.
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
Posté par floriang . Évalué à 4.
[^] # Re: Question provoc
Posté par Éric (site web personnel) . Évalué à 2.
> 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
Posté par CrEv (site web personnel) . Évalué à 2.
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
Posté par Serge Stinckwich (site web personnel) . Évalué à 2.
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
Posté par Damien Cassou . Évalué à 2.
[^] # Re: Question provoc
Posté par Jean-Philippe (site web personnel) . Évalué à 6.
[^] # Re: Question provoc
Posté par Damien Cassou . Évalué à 2.
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.
[^] # Re: Question provoc
Posté par Serge Stinckwich (site web personnel) . Évalué à 1.
# Doc en Français
Posté par Benjamin Poulain (site web personnel) . Évalué à 6.
La documentation est un peu vieille mais globalement toujours d'actualité. Ça peut servir à un débutant par exemple.
[^] # Re: Doc en Français
Posté par totof2000 . Évalué à 6.
Reultat : trop peu de documentation sur le sujet. Aller voir le code source et l'implémntation des composants, contrairement à ce que prétndent certains, ne suffit absolument pas .... Faut pas s'étonner de ce fait si peu de monde s'y met.
Je n'abandonne pas complètement l'affaire, seulement, je n'ai pas en ce moment de soirées à passer pour décoder l'implémentation du bazar, je verrai ça plus tard.
[^] # Re: Doc en Français
Posté par Serge Stinckwich (site web personnel) . Évalué à 5.
Il commence a y avoir plusieurs tutoriels en anglais et en français (voir ici pour quelques liens : http://doesnotunderstand.free.fr/?cat=23 ) Nous avons également des pages dans le wiki Squeak-fr : http://community.ofset.org/index.php/Seaside
Bon, c'est vrai ces pages sont un peu obsolètes, il faudrait les remettre à jour à partir à la dernière version de Seaside.
[^] # Re: Doc en Français
Posté par Damien Cassou . Évalué à 1.
[^] # Re: Doc en Français
Posté par totof2000 . Évalué à 4.
[^] # Re: Doc en Français
Posté par Damien Cassou . Évalué à 3.
[^] # Re: Doc en Français
Posté par totof2000 . Évalué à 4.
Je veux bien, c'est pratique quand tu sais quelle classe utiliser. Pour en revenir à ma comparaison avec l'elecronique, si tu as besoin d'un élément qui réalise une amplification de courant, tu sais que tu dois utiliser un transistor, et tu sais à partir de ton besoin, quel transistor tu vas choisir ( éventuellement tu fais un petit montage avec appareils de mesure pour vérifier ton choix, ou tu utilises un simulateur).
Ce qui fait que quand tu souhaites utiliser une classe, tu commences par ouvrir un navigateur de code sur cette classe et tu peux voir immédiatement son commentaire et ses méthodes.
Le problème se pose dans le cas inverse: tu veux effectuer une opération mais tu ne sais pas quelle classe utiliser: il est un peu fastidieux d'ouvrir les classes une à une pour s'y retrouver. Pour Seaside c'est encore pire, a l'époque ou j'ai tenté de l'utiliser (6 mois environs), même le code n'était pas documenté.
C'est un des gros avantages par rapport à une approche de type documentation séparée : on a la doc et le code juste sous la main pour bien voir ce qui se passe.
C'est pratique mais incomplet à mon avis, surtout pour débuter.
[^] # Re: Doc en Français
Posté par Ummon . Évalué à 2.
Personnellement je trouve bien d'avoir toute la documentation liée avec le code, ça la rend plus accessible pour le programmeur.
Évidemment cela va de paire avec un outil comme Doxygen pour l'extraire et la présenter à l'utilisateur.
[^] # Re: Doc en Français
Posté par CrEv (site web personnel) . Évalué à 4.
Alors que lorsque la doc est réellement à côté, il arrive fréquement que celle-ci soit en décalage.
[^] # Re: Doc en Français
Posté par Serge Stinckwich (site web personnel) . Évalué à 2.
Si vous ne connaissez pas ce principe de développement par les tests, je vous invite à venir à la séance de Dojo XP (eXtreme Programming) que nous organisons à la prochaine SmalltalkParty le 1ier décembre à Paris :
http://linuxfr.org/2007/10/25/23254.html
[^] # Re: Doc en Français
Posté par totof2000 . Évalué à 2.
une documentation externe (même si elle parfois nécessaire) est très vite en décalage par rapport au code. Aujourd'hui, la documentation devient du code exécutable
Ce serait bien alors un outil qui irait extraire la documentation du code source des classes .... parce que lorsque tu as besoin d'effectuer une action précise, c'est pas génial d'explorer les classes une à une pour savoir laquelle répond le mieux à tes besoins.
# Autre documentation
Posté par weeber (site web personnel) . Évalué à 3.
Je ne connais pas du tout seaside, quel est/sont le/les avantage/inconénients par rapport à du php + mysql, plus rapide à dévelloper?
J'espère que ma question n'est pas trop bête...
Sinon j'ai trouvé une autre doc francaise:
http://www.magellan.fpms.ac.be/articles/seaside/?searchterm=(...)
Bonne soirée
[^] # Re: Autre documentation
Posté par Damien Cassou . Évalué à 1.
- l'approche composant qui permet de vraiment découper son application web en petites parties réutilisables.
- la génération de code XHTML à partir de code Smalltalk.
- les outils de développement directement accessible dans le navigateur.
- sa simplicité une fois qu'on a lâché les ponts avec ce que l'on connaît déjà.
- le langage Smalltalk
# "scalabilite"
Posté par Erwan . Évalué à 3.
C'est-a-dire - est-ce facile d'avoir plusieurs serveurs web, plusieurs serveurs de bases de données ou est-ce que tout ca est tout melangé ?
[^] # Re: "scalabilite"
Posté par Serge Stinckwich (site web personnel) . Évalué à 2.
[^] # Re: "scalabilite"
Posté par Damien Cassou . Évalué à 2.
[^] # Re: "scalabilite"
Posté par totof2000 . Évalué à 2.
# Rapidité
Posté par Pierre Tramonson . Évalué à 1.
Est-ce qu'il sert les pages plus rapidement qu'Apache ?
Parce que bon, c'est quand même une des marques de distinction des framework web de qualité; toute ressemblance avec <![troll[ un ~langage() basé sur PHP étant bien évidemment involontaire. ]troll]>
[^] # Re: Rapidité
Posté par CrEv (site web personnel) . Évalué à 2.
Apache sert les pages qui on été rendu par le framework.
si on prend un framework en ruby, un en python et un en php, ils peuvent très bien être tous les trois servis par apache... (pour seaside j'en sais rien, j'ai pas regardé...)
Entre deux applis web (framework + serveur) les deux éléments peuvent jouer pour le temps jusqu'au client mais sont différents.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.