Seaside 2.7

Posté par  . Modéré par Nÿco.
Étiquettes :
0
2
avr.
2007
Technologie
Une nouvelle version de Seaside vient de sortir. Seaside est un serveur d'applications web libre pour Smalltalk : il fonctionne notamment avec Squeak. Seaside utilise une architecture à base de composants qui permet de construire une page comme une hiérarchie de composants plus simples. La principale originalité de Seaside est d'utiliser les continuations pour modéliser des flots multiples d'interactions entre différents composants.

Cette version 2.7 apporte un lot important de changements parmi lesquels :
  • Une nouvelle technique de rendu par défaut,
  • Une bibliothèque pour gérer facilement les fichiers (FileLibrary),
  • Une API de dépréciation (deprecated),
  • La possibilité de cliquer dans le code HTML généré afin d'ouvrir un debuggueur automatiquement au bon endroit,
  • De nombreux bugs corrigés.

Une version 2.8 est déjà en développement afin d'améliorer les performances de Seaside. Le site web CMSbox l'utilise déjà. Des présentations, vidéos et de la documentation peuvent être trouvées sur le site de Lukas Renggli, un des deux développeurs de Seaside les plus actifs. On trouvera plusieurs tutoriels sur le blog Inching Forward.

Aller plus loin

  • # comparaison Rails vs Seaside

    Posté par  . Évalué à 5.

    cette page d'un blog décrit vite fait le code pour réaliser la même page bien classique (liste de recettes, liens pour en rajouter ou éditer une), d'abord en RoR puis en Seaside

    http://onsmalltalk.com/programming/smalltalk/rails-vs-seasid(...)

    suivant vos penchants naturels, l'une des deux vous fera dire "beurk". après, pour savoir laquelle...

    • [^] # Re: comparaison Rails vs Seaside

      Posté par  . Évalué à 4.

      Difficile de dire beurk a l'un, les deux sont différents, c'est tout.

      Ceci dit la syntaxe de Smalltalk est quand même un poil difficile a avaler quand on est habitué a la famille des langages C..
      Je me suis souvent demandé si un Smalltalk avec une syntaxe qui ressemblerait plus a celle du C ({} pour les blocs de code, ';' pour les fins de lignes mais en gardant les bonnes idée de Smalltalk: appels par mots-clef, espace comme séparateur pour les listes) n'aurait pas eu plus de succès..

      • [^] # Re: comparaison Rails vs Seaside

        Posté par  . Évalué à 3.

        La syntaxe Ruby n’est pas franchement C non plus, elle me semble pourtant plus facile à avaler par tout un chacun.

      • [^] # Re: comparaison Rails vs Seaside

        Posté par  (site web personnel) . Évalué à 5.

        j'ai du apprendre smalltalk dans le cadre d'un projet de génie logiciel (avec seaside, en utilisant visualworks.)

        Il y a une notion qui est très utile et qui marche pas trop mal, c'est que *tout code est objet*. C'est à dire qu'il existe des "blocs" comme tu dis:
        [moncode.]
        L'interet, c'est qu'on peut passer du code en parametre, et faire ainsi des callbacks très reactifs. Par ex je me souviens qu'en seaside on pouvait incrémenter un compteur à partir d'un lien de cette manière:

        html add: Link new onClicked:[compteur = compteur+1.].
        (pour ceux qui sont novices, l'équivalent du . ou -> du C++ est l'espace, tout se lit de gauche à droite, les appels de methode sont des :, l'allocation d'un nouvel objet est l'appel de la methode new sur sa classe (qui est aussi un objet) et les instructions se terminent par un .)

        le langage a des particularités très interessantes, mais c'est dommage que les environnements ne soient pas plus attractifs (les 2 premières semaines avec visualworks n'ont pas été très facile).

      • [^] # Re: comparaison Rails vs Seaside

        Posté par  . Évalué à 4.

        Je ne pense pas que la syntaxe aurait beaucoup changé son sort.

        Elle est parfois étrange, mais parfois très utile : rien que pour les fonctions qui prennent beaucoup de paramètres, ou alors des paramètres qui se "ressemblent" (par exemple foo(width,height) qui serait appelé comme ça : foo(5,8)), on sait tout de suite quel paramètre correspond à quoi : fooWithWidth: 5 andHeight: 8 (mon expérience vient de l'Objective C, d'où le nommage bizarre, mais la syntaxe est assez similaire à Smalltalk). Bon, c'est vrai que quand on a les paramètres "nommés" comme en Python, ça devient aussi pratique (même plus, puisqu'il n'y a pas d'ordre précis).

      • [^] # Re: comparaison Rails vs Seaside

        Posté par  (site web personnel) . Évalué à 5.

        Ceci dit la syntaxe de Smalltalk est quand même un poil difficile a avaler quand on est habitué a la famille des langages C.

        Oui c'est sur, c'est vraiment insurmontable d'apprendre une syntaxe concise. Et puis C est tellement limpide pour manipuler des tableaux de pointeurs de fonctions...

        • [^] # Re: comparaison Rails vs Seaside

          Posté par  . Évalué à 2.

          Pas insurmontable bien sur, mais je pense que tu sous-estime l'impact de la syntaxe, surtout quand on n'as pas beaucoup d'expérience..

          Je me souviens d'une introduction a Smalltalk quand j'étais étudiant, la syntaxe m'avait beaucoup géné, maintenant beaucoup moins..

          Mais n'utilisant pas Smalltalk quand je vois un extrait de code [] a la place de {}, ça me gêne du point de vue lisibilité, certes on doit s'y habituer rapidement mais cela ne permet pas de comparer deux extraits de codes facilement..

          • [^] # Re: comparaison Rails vs Seaside

            Posté par  (site web personnel) . Évalué à 3.

            Je me souviens d'une introduction a Smalltalk quand j'étais étudiant, la syntaxe m'avait beaucoup géné, maintenant beaucoup moins..

            Oui, pense à la première fois ou tu as vu du Java ou du C... est-ce qu'on met un ; après une classe, un typedef ? Dans un typedef, celui qu'on définit c'est le premier ou le dernier ? Dans int* i,j,k; pourquoi j et k ne sont pas des pointeurs, etc etc

            En Smalltalk tu apprends une fois pour toutes les 3 types de messages, les blocs, et les différents littéraux et c'est fini.

      • [^] # Re: comparaison Rails vs Seaside

        Posté par  (site web personnel) . Évalué à 1.

        Je pense que ce n'est pas difficile de faire une syntaxe C/Java pour Smalltalk. Il y a tout ce qu'il faut pour le faire en terme de parseur notamment. Après je vois pas trop l'intérêt ... Tu vas écrire {} au lieu de [] pour représenter des blocs ? Mais tu peux envoyer des messages aux blocs Smalltalk, comment vas tu écrire cela ?

        Essayons :

        [3+4. Date today] value.

        devient :

        {3+4; Date.today();}.value();

        Tu pense que c'est plus clair ?

        • [^] # Re: comparaison Rails vs Seaside

          Posté par  . Évalué à 2.

          > [3+4. Date today] value.
          vs
          > {3+4; Date.today();}.value();

          Il me semble que ça devrait être:
          [3+4. ^Date today] value.
          {3+4; ^Date.today();}.value();
          Enfin je pense, je ne m'y connais pas beaucoup en Smalltalk..

          Mais oui, pour moi habitué au C/C++, c'est vraiment beaucoup plus simple de lire la deuxième version que la première..

          • [^] # Re: comparaison Rails vs Seaside

            Posté par  (site web personnel) . Évalué à 2.

            Le ^ n'est pas nécessaire dans ce cas la.
            Je suis d'accord avec toi que l'on n'aime pas changer ses habitudes ... cela veut dire que tous les langages que nous allons utiliser dans le futur devront tous avoir une syntaxe proche de celle de C ... c'est un peu triste comme perspectives ...

            C'est comme les étudiants d'informatique d'aujourd'hui, ils ne connaissent plus qu'une syntaxe (C), qu'un langage de programmation (Java) ... exit Ocaml, Prolog, Lisp, Haskell, Smalltalk, ADA, etc ... c'est la mono-culture, donc forcemment cela appauvrit les esprits.

          • [^] # Re: comparaison Rails vs Seaside

            Posté par  (site web personnel) . Évalué à 3.

            En ce qui concerne la différence entre la syntaxe de Smalltalk vs celle de C, vous pouvez lire avec intérêt le billet suivant : http://onsmalltalk.com/programming/smalltalk/why-smalltalk/

            En fait, ce qui est important dans Smalltalk ce n'est pas la syntaxe, c'est l'environnement. Il faut le pratiquer pour le comprendre et pas uniquement lire des bouts de code sur du papier.

            L'exemple qu'il prend est le suivant :

            - avec une syntaxe C :

            Window window = new Window(0, 0, 800, 600);

            - avec une syntaxe Smalltalk :

            window := Window top: 0 left: 0 width: 800 height: 600.

            C'est beaucoup plus expressif en Smalltalk qu'en C. On comprend en ST que les 4 paramètres sont la position de la fenêtre, sa largeur et sa longueur. C'est impossible avec la syntaxe C/Java, il faut aller voir le code du constructeur pour connaiître la signification des paramètres.

            • [^] # Re: comparaison Rails vs Seaside

              Posté par  . Évalué à 3.

              Je ne dis pas que la syntaxe du C est meilleure que celle de Smalltalk juste que malgrès sa "clarté" pour toi, la syntaxe Smalltalk n'est pas si évidente..
              Une syntaxe hybride serait bien plus lisible pour les gens habitués au C que du pur Smalltalk, par exemple:

              window := Window.new(top:0 left:0 width:800 height:600);

              • [^] # Re: comparaison Rails vs Seaside

                Posté par  (site web personnel) . Évalué à 3.

                Oui, je suis conscient que c'est pas facile de sortir de ce que l'on connait. Il est difficile de se mettre dans la peau d'un débutant Smalltalk. Mais pour un débutant en informatique, la syntaxe C ne devrait pas sembler plus difficile que celle de Smalltalk.

                C'est clair que c'est pas difficile de communiquer :
                - les Smalltalkiens ne comprennent pas pourquoi il faudrait compliquer leur syntaxe pour se faire comprendre des Cistes,
                - les Cistes ne comprennent pas pourquoi il leur faudrait apprendre une autre syntaxe que celle du C.

              • [^] # Re: comparaison Rails vs Seaside

                Posté par  (site web personnel) . Évalué à 4.

                L'être humain est ainsi fait qu'il résiste naturellement aux changements, c'est sans doute lié à l'esprit de survie, c'est somme toute salutaire, et cela s'applique à chacun de nous.

                L'approche d'un nouveau langage passe donc par les mêmes mécanismes : c'est différent de ce que je connais, cela implique donc un coût d'apprentissage d'initial. Il s'agit donc d'évaluer le ratio coût/bénéfice.

                Avant de m'essayer à Smalltalk, j'ai pratiqué du C/C++ pendant des années (cf. le logiciel libre de géométrie Dr.Geo). Ce que j'ai pu constater en pratiquant Smalltalk c'est qu'il y a un changement de plan conceptuel sur la façon d'aborder le processus de développement. Cela ne veut pas dire que c'est plus compliqué, au contraire tout est globalement plus simple, accessible et compréhensible avec Smalltalk, il y a simplement un changement de plan conceptuel. D'un point de vu qualitatif, cela m'a permis d'apprendre beaucoup et beaucoup plus facilement/vite.

                A propos de l'intelligence augmentée avec des dispositifs informatiques, Doug Engelbart -- l'inventeur de la souris -- fait une comparaison intéressante: il est très facile de faire du vélo avec un tricycle, en revanche avec une bicyclette c'est plus difficile au départ, mais une fois maîtrisée la bicyclette permet d'aller plus vite et plus loin. C'est la même chose avec Smalltalk.

                • [^] # Re: comparaison Rails vs Seaside

                  Posté par  (site web personnel) . Évalué à 1.

                  Oui et c'est plus facile d'apprendre avec un outil simple et minimaliste même s'il semble contre-intuitif au premier abord, qu'avec l'outil final plus de l'assistance.

                  Pour reprendre la métaphore de l'apprentissage du vélo, ce qui est dur c'est de prendre assez de vitesse pour avoir le temps de mettre les pieds sur les pédales et ensuite essayer de garder l'équilibre. Donc en général on ajoute des roulettes... mais du coup l'enfant apprend à pédaler mais pas à tenir l'équilibre.

                  Si au contraire on prend un vélo sans roulettes, et qu'on enlève les pédales (une draisienne), c'est très facile de courir et de se laisser rouler ou de profiter des descentes. L'apprentissage est plus progressif, plus drôle, et une fois l'équilibre acquis c'est immédiat de gérer les pédales.

                  roulettes -> IDE, typage, public static void synchronized {}; etc
                  draisienne -> syntaxe minimaliste, modèle objet avec l'essentiel et pas de bruit (et on remet les pédales en abordant le test unitaire, les refactorings et la métaprogrammation :-)

  • # Installation de Seaside

    Posté par  . Évalué à 4.

    Pour installer Seaside, vous avez besoin d'une machine virtuelle ainsi que de l'image.

    - La machine virtuelle peut se trouver dans votre système de paquetage si vous en avez un. Sinon : http://www.squeakvm.org/.

    - Vous trouverez l'image sur le site officiel ou directement sur http://damien.cassou.free.fr/squeak-web/.

    Pour avoir le code source de Squeak et éviter un message d'erreur au démarrage, télécharger http://damien.cassou.free.fr/squeak-dev/SqueakV39.sources et placer le fichier avec la VM ou avec l'image.

    N'hésitez pas à demander sur les mailing listes ou sur IRC. Voir http://www.squeak.org/Community/.

  • # Langage des dinosaures

    Posté par  . Évalué à 1.

    Ah les joies du squeak et de seaside !!!

    Je dirais même que l'interface play school, c'est quelque chose, inutilisable, complétement anti ergonomique.

    Ensuite seaside, c'est 0 doc, et pas la peine de me dire que le smalltalk c'est auto-documenté, et que les gens qui pratiquent ont la flemme d'écrire la doc ....

    Ensuite le seul avantage de seaside c'est d'avoir le debuguer intégré, et ça c'est The feature que beaucoup de gens rêvent d'avoir !!!!

    Enfin bon le smalltalk reste et restera un langage de roger le bricolo pour des fanatiques. Ce qui me fait rire c'est soit disant un langage 100 % objet sans notion de privée !!!!

    @+ dans le bus

    • [^] # Re: Langage des dinosaures

      Posté par  . Évalué à 3.

      @+ dans le bus


      Sous le bus.

    • [^] # Re: Langage des dinosaures

      Posté par  . Évalué à 2.

      >Ce qui me fait rire c'est soit disant un langage 100 % objet sans notion de privée !!!!

      Bof, quel est le si grand avantage d'avoir la notion de privée par rapport a une convention (genre tout ce qui débute par un _ est privé a l'objet)?

      Dans les langages qui ont la notion de privée, a coup de cast/reflexion/etc, tu peux facilement accéder aux champs privé..

      Un truc que je trouve pas terrible dans Smalltalk est la déclaration des variables au début du bloc, une idée qui a fait son temps et a ajouter a la liste des mauvaise idée dont on doit se débarrasser: la déclaration des variable lors de leur première affectation est une bien meilleure idée.

      • [^] # Re: Langage des dinosaures

        Posté par  . Évalué à 3.

        Enfin n'oublions tout de meme pas les apports interessants de ce langage comme MVC ou le refactoring...

      • [^] # Re: Langage des dinosaures

        Posté par  . Évalué à 2.

        > Un truc que je trouve pas terrible dans Smalltalk est la déclaration des variables au début du bloc, une idée qui a fait son temps et a ajouter a la liste des mauvaise idée dont on doit se débarrasser: la déclaration des variable lors de leur première affectation est une bien meilleure idée.

        Le problème ne se pose pas vraiment en Smalltalk. La taille moyenne d'une méthode doit être de 7 lignes environ. Contrairement aux autres langages, déclarer toutes les variables au début du bloc rend le code plus court : on déclare toutes les variables en une seule ligne. Par exemple pour déclarer 2 variables :

        |persons folders|

        • [^] # Re: Langage des dinosaures

          Posté par  . Évalué à 2.

          Certes les méthodes sont souvent courtes, mais il n'empêche que ta variable est dans un état intermédiaire 'nil' entre sa déclaration et son utilisation, ce qui peut induire des erreurs..

          Personnellement, je pense qu'entre deux constructions équivalentes de langages, celle qui induit le moins d'erreur, à lisibilité équivalente, est préférable, même si le nombre d'erreur induit est faible: c'est toujours ça de gagné!

          Il est possible de faire très simple pour la déclaration:
          var foo = pour la déclaration et l'initialisation
          ou comme en Limbo:
          foo := pour la déclaration et l'initialisation
          et foo = pour la modification d'une variable déjà déclarée.

          • [^] # Re: Langage des dinosaures

            Posté par  (site web personnel) . Évalué à 1.

            Seulement lorsque tu veux sauvegarder ta méthode, l'environnement te crie dessus si jamais les variables ne sont pas initialisées, ne sont pas utilisées, etc. Et l'environnement, c'est Smalltalk (en effet, Smalltalk n'est pas un langage au sens habituel du terme mais un véritable environnement de dév et d'exécution d'objets)
            Donc, finalement ...

          • [^] # Re: Langage des dinosaures

            Posté par  (site web personnel) . Évalué à 1.

            Certes les méthodes sont souvent courtes, mais il n'empêche que ta variable est dans un état intermédiaire 'nil' entre sa déclaration et son utilisation, ce qui peut induire des erreurs..

            En général on s'en rend compte vite de ce genre d'erreur, donc elles sont assez bénignes. C'est le même argument que pour le typage statique : la moindre erreur fait tout péter, donc c'est vite fixé... et comme tu est un développeur sérieux tu as plein de tests unitaires, n'est-ce pas ?

            foo := pour la déclaration et l'initialisation
            Sauf que ça disperse les déclarations de variables dans le code, donc il faut les chercher. Or si il y a bien qqch d'important, c'est de savoir si tu as affaire à une variable locale ou une variable d'instance... c'est pour ça que je préfère avoir toutes les variables locales déclarées au même endroit.

            • [^] # Re: Langage des dinosaures

              Posté par  . Évalué à 4.

              >En général on s'en rend compte vite de ce genre d'erreur, donc elles sont assez bénignes.

              Sauf dans les cas ou on ne s'en rend pas compte, bien sur (affectation de la variable dans un if), et la le bug arrive en production..

              >tu est un développeur sérieux tu as plein de tests unitaires, n'est-ce pas ?

              Les développeur "sérieux" qui testent toutes les combinaison de branchements dans leur code, ça n'existe pas: beaucoup trop de combinaisons possibles.

              >Sauf que ça disperse les déclarations de variables dans le code, donc il faut les chercher.

              Bof, c'était le même argument pour le C ou le Pascal, en pratique en C++ je n'ai jamais eu le problème de lister les variables locales d'une fonction..

              >Or si il y a bien qqch d'important, c'est de savoir si tu as affaire à une variable locale ou une variable d'instance

              Bin je ne connais pas l'environnement de dev Smalltalk, mais il ne pourrait pas tout simplement utiliser une coloration pour indiquer la différence?
              Une convention de nommage peut faire l'affaire aussi (avantage, c'est imprimable).
              Ruby impose $ et @ pour différencier les types d'accès, ce qui permet très simplement d'éviter ce genre de confusion.

              • [^] # Re: Langage des dinosaures

                Posté par  (site web personnel) . Évalué à 1.

                > le bug arrive en production..

                Eh ben il arrive et il est vite fixé... me dis pas que les clients mettent immédiatement tout l'avenir de leur boite sur un nouveau système en prod :)

                > Les développeur "sérieux" qui testent toutes les combinaison de branchements dans leur code, ça n'existe pas

                Non évidemment, on en oublie toujours, mais avec une couverture raisonnable tu attrapes vite beaucoups de bugs. C'est une histoire de confiance et de compromis. Enfin en tant que client ça m'ennuierait d'acheter un truc qui contient du code non testé, qu'il soit typé/initialisé statiquement ou pas...

                > Bin je ne connais pas l'environnement de dev Smalltalk, mais il ne pourrait pas tout simplement utiliser une coloration pour indiquer la différence?

                Si bien sûr, les outils Smalltalk colorisent comme il faut. Mais ça n'aide que la lecture, pas l'écriture. En fait tu peux taper ton code sans rien déclarer, et au moment de sauver la méthode, le browser te demande "euh, foo est pas déclaré, est-ce que je dois ajouter une var locale, une d'instance, renommer parce que c'est une typo, ou rien faire et compiler du code cassé?"

                > Ruby impose $ et @ pour différencier les types d'accès

                En Ruby le problème est de savoir quels sont les attributs d'une classe. Si il n'y a pas de attr_accessor ou similaires, il faut aller regarder dans toutes les méthodes et toutes les extensions de la classe dans différents modules et compter les @trucs.

    • [^] # Re: Langage des dinosaures

      Posté par  . Évalué à 4.

      C'est vrai que ca
      http://www.dabbledb.com/
      ca fait dinosaures.

      Ils ont de la chance ces dinosaures.
      Domage que tu vives pas a la même époque qu'eux

    • [^] # Re: Langage des dinosaures

      Posté par  . Évalué à 3.

      Enfin bon le smalltalk reste et restera un langage de roger le bricolo pour des fanatiques. Ce qui me fait rire c'est soit disant un langage 100 % objet sans notion de privée !!!!

      Ca c'est du troll de compétition !

  • # Pour les fans de framework web en langages exotiques

    Posté par  . Évalué à 4.

    J'ai découvert il n'y pas pas longtemps Lift : http://liftweb.net/ (par ce blog : http://blog.lostlake.org/index.php?/archives/45-A-real-world(...) qui fait la comparaison avec Rails)(je suis parti d'ici d'ailleurs : http://lambda-the-ultimate.org/node/2147 où se trouve un commentaire de l'auteur du blog détaillant un peu plus son choix)
    Un framework web écrit en Scala ( http://www.scala-lang.org/ ) qui a l'air très intéressant (bon, surtout parce que j'aime bien Scala). En plus, ça tourne sur une JVM, donc ça pourrait être "daïcidor-friendly".

    Je sais, ça n'est pas du Smalltalk, mais Scala est un langage moderne très intéressant, qui offre un typage statique qui évite de faire trop de conneries, et des paradigmes sympas (un peu de fonctionnel, avec de l'objet, de la programmation par acteur, on peut même faire de la prog par contrainte, etc...). Et tout ça en éclatant Ruby niveau perf (OK, ça n'est pas le point fort de Ruby de toutes façons...)

    • [^] # Re: Pour les fans de framework web en langages exotiques

      Posté par  . Évalué à 3.

      Pour les (futurs?) fans d'ocaml, il y a le serveur web/framework http://ocsigen.org/ qui est vraiment sympa.

      • [^] # Re: Pour les fans de framework web en langages exotiques

        Posté par  . Évalué à 1.

        Mouais
        alors moi jaime bien ocaml, jaime bien lisp, jaime bien smalltalk (en tout cas squeak) et seaside m'a pas mal bluffé, tout comme rails et ruby. Ya pas longtemps jme suis même mis au D...

        pis ya pas longtemps jme suis dit "tient jvais me chercher un nouvel emploi, question de me faire plus de pépette", j'ai cherché, pis jme suis dit : bon à partir de maintenant je n'apprends que des technos qui me serviront un jour.

        • [^] # Re: Pour les fans de framework web en langages exotiques

          Posté par  . Évalué à 3.

          Bah oui, ce serait triste si les entreprises réfléchissaient un peu plus à long terme, et payaient un peu plus pour des informaticiens capables de programmer avec des frameworks modernes : il n'y aurait plus de boulot pour la moitié des programmeurs de la planète (dont on retrouve souvent les idées de génie ici : http://thedailywtf.com )

        • [^] # Re: Pour les fans de framework web en langages exotiques

          Posté par  (site web personnel) . Évalué à 1.

          En même temps, tu sait jamais quand un langage "exotique" te sera utile -- au cours d'un entretien d'embauche j'ai eu une boite qui m'a demandé si j'avais déja programmé en ... PostScript (!!) -- la raison étant qu'ils avaient un langage maison implémentant de la logique métier, assez proche de PS (stack-based quoi).

          De façon moins anecdotique, je trouve qu'avoir programmé en lisp ou smalltalk (ou autre langage dynamique) change assez radicalement la façon dont on programme par la suite, même si on se retrouve à faire du C/C++/Java. Et en règle générale je suis persuadé qu'on s'enrichit beaucoup au contact de langages "exotiques" -- ça permet d'avoir une autre approche à son arc...

      • [^] # Re: Pour les fans de framework web en langages exotiques

        Posté par  . Évalué à 2.

        Pas mal : comme tous les frameworks des langages "haut niveau", il est basé sur des light-threads, mais comme Seaside, il utilise les continuations pour modéliser le "parcours" des pages. Lift utilise plutôt un modèle acteur. Je ne sais pas trop comment les comparer (je ne suis pas trop dans le dev web), mais c'était aussi pour montrer une approche différente que je parlais de Lift : je trouve que Ocsigen ressemble pas mal à Seaside, avec un "défaut" pour moi, c'est le HTML dans le code. OK, ça leur permet de dire "on fait du XHTML _typé_ à la compilation", mais alors c'est un mélange que j'hésite un peu à faire, surtout si le HTML doit être retravaillé par des graphistes.

  • # performances seaside

    Posté par  . Évalué à 1.

    J'utilise J2EE comme framework web depuis quelques années déjà.

    J'ai regardé seaside récemment et certains concepts me semblent très prometteurs (on approche le mythe du composant web réutilisable, débogage à distance)

    Au niveau performance, y a-t-il des comparaisons avec d'autres systèmes (tomcat par exemple) ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.