Sortie de Blitzen 0.0.8

Posté par (page perso) . Modéré par Bruno Michel.
Tags :
15
12
nov.
2010
Internet
Blitzen est un serveur d'applications déjà présenté ici à travers un journal et une dépêche à l'occasion des deux précédentes versions. En résumé, il s'agit d'un projet visant à permettre l'écriture de sites ou applications web via une API proche de celle de GTK+. Il s'agit donc d'une approche orientée composants, fournissant une abstraction totale des technologies sous-jacentes (HTML, JavaScript, CSS...).

Blitzen est écrit en C/GObject. Bien qu'il soit possible d'écrire des sites web directement en C/GObject, son but premier est de permettre l'écriture des applications en Vala. Les applications sont compilées sous la forme de shared objects (so) qui sont ensuite déployés et instanciées à la demande, sur le modèle des serveurs d'application Java. Blitzen vise à allier la simplicité des frameworks orientés composants avec le niveau de performance du code natif.

D'autre part, de nombreux frameworks se définissant comme component oriented obligent parfois le développeur à manipuler directement les technologies web tant redoutées. Certains rendent délicate la manipulation ou l'ajout d'éléments d'interface après sa définition. Blitzen vise à être le plus proche possible de l'API des applications desktop.

Les corrections de bugs et autres optimisations mises à part, la principale nouveauté de cette nouvelle version 0.0.8 est l'arrivée d'une interface de construction des vues (pages) basée sur des fichiers XML. Il est désormais possible de séparer le code applicatif de la description de l'interface. Cette infrastructure permet l'autoconstruction des pages avec un minimum de code, comme détaillé dans la seconde partie de la dépêche.

NdM : Blitzen est sous licence LGPLv2 Dans cette version 0.0.8 de Blitzen, une nouvelle manière de construire les vues (pages) a été introduite. Comme un extrait de code vaut mieux qu'un long discours, voici un exemple type de construction d'une vue:

public class HelloView : View {
public Label txtLbl;
public Label welcomeLbl;
public Entry nameEntry;
public Button okBtn;
public FlowContainer flow;

construct{
this.txtLbl = new Label.with_text("Enter your name : ");
this.welcomeLbl = new Label();
this.nameEntry = new Entry();

        this.okBtn = new Button.with_label("Ok");
        this.okBtn.set_navigate_mode(false,false);
        this.okBtn.clicked += this.on_button_clicked;

        this.flow = new FlowContainer();
        this.flow.add_child(this.txtLbl);
        this.flow.add_child(this.nameEntry);
        this.flow.add_child(this.okBtn);
        this.flow.add_child(this.welcomeLbl);

        this.set_child(this.flow);
    }
    […]
}

Comme on le voit, chaque widget est construit « à la main » et la structure de l'interface, l'imbrication des containers, est définie de la même manière.

En utilisant la nouvelle interface de construction d'interface, nommée StkBuilder, le code précédent devient:

public class HelloView : View {
    public Label txtLbl { get; set; }
    public Label welcomeLbl { get; set; }
    public Entry nameEntry { get; set; }
    public Button okBtn { get; set; }
    public FlowContainer flow { get; set; }

    construct{
        this.build_from_spec(null);
        this.okBtn.clicked += this.on_button_clicked;
    }
[…]
}

Toute la magie réside dans la méthode StkView.build_from_spec(); Cette méthode permet de construire l'interface suivant une définition située dans un fichier XML. Si aucun fichier n'est spécifié (utilisation d'un paramètre « null »), comme dans l'exemple présent, StkBuilder tentera d'ouvrir un ficher XML de la forme ClassName.xml.

Le fichier HelloView.xml définit l'interface de la manière suivante:
<class name="HelloView" parent-class="StkView" title="Hello View">
    <object class="StkFlowContainer" backed-on="flow" />
        <object class="StkLabel" text="Enter your name: " backed-on="txtLbl" />
        <object class="StkEntry" backed-on="nameEntry" />
        <object class="StkLabel" backed-on="welcomeLbl" />
        <object class="StkButton" backed-on="okBtn" label="Ok" navigate="false" mix-replace="false" />

La définition d'une interface reprend l'imbrication des widgets. Il est également possible de spécifier les propriétés de chaque objet directement dans le tag associé. L'originalité de StkBuilder est de ne pas forcer le développeur à interroger le système de construction pour obtenir un pointeur sur les objets instanciés. StkBuilder met le paramètre « backed-on » à la disposition du développeur. Ce paramètre permet, grâce au système de propriétés de GObject, d'associer un widget à un des membres de la classe. Ainsi, à l'issue du processus de construction, un pointeur sur l'objet associé est disponible via les membres de la classe, de la même manière que si l'interface avait été construite « à la main »

Il ne reste plus au développeur qu'à associer signaux et callbacks. En effet, l'autoconnexion de signaux n'est pas encore implémentée. Cette fonctionnalité sera disponible dans la prochaine version de Blitzen.
  • # Harmonisation

    Posté par . Évalué à 4.

    Vala est un langage encore jeune mais dynamique, pas mal de monde semble avoir envie d'en faire quelque chose, et je trouve ça chouette. Mais ça serait peut-être encore mieux si c'était fait de manière organisée. J'ai vu que tu avais présenté ton projet sur la ML vala-list ; est-ce que tu la fréquentes depuis longtemps ? As-tu vu les discussions sur Gtkaml, le XML dédié aux interfaces GTK+ ? Et celles sur Gtkon, l'équivalent JSON ?

    Ça pourrait être bien de regrouper autant que possible vos différents travaux non ?
    • [^] # Re: Harmonisation

      Posté par (page perso) . Évalué à 5.

      Je ne fréquente pas du tout la mailling-list de Vala, c'est la première fois que je poste dessus. En effet, j'ai préféré attendre d'avoir un feature set minimal avant de parler de Blitzen. Maintenant que j'ai presque fini de jeter les bases que le projet commence à ressembler à quelque chose, j'ai décidé qu'il était temps d'en parler aux devs de Vala themselves et également aux différentes personnes qui s'y intéressent, d'où le post sur la mailling list.

      En ce qui concerne Gtkaml, je ne connaissais absolument pas. Je viens de regarder ce que c'est, et ça ne me semble pas convenir à ce que je souhaite mettre en place. Gtkaml mélange le code et l'UI. Ce n'est pas ce que je souhaite faire. D'autre part, c'est Vala-only alors que GtkBuilder est intégré à Gtk et utilisable dans tous les langages qui ont un binding Gtk. Gtkaml est un générateur de Vala à partir d'une syntaxe XML. Très franchement, mis à part pour du prototypage rapide, je trouve que c'est une très mauvaise idée. En plus, il faut régler le parseur avec un fichier ini, pour lui apprendre quelles sont les méthodes à utiliser. C'est à des années lumières de ce que je veux faire.

      StkBuilder est beaucoup plus proche de GtkBuilder: C'est uniquement un moyen de décrire un interface. Ils différent seulement par quelques éléments de syntaxe, mais l'esprit est le même. La principale différence entre StkBuilder et GtkBuilder est que StkBuilder vise a automatiser le maximum de choses, et surtout construire un interface qui s'appuie sur une classe, en plaçant des pointeurs sur les objets construits dans les propriétés de cette classe, alors que GtkBuilder donne un pointeur sur une interface abstraite qu'il faut interroger pour récupérer un pointeur sur l'objet avec lequel on souhaite travailler.

      D'autre part, StkBuilder n'est pas vraiment lié au XML. StkBuilder est coupé en deux: Une partie qui construit une représentation abstraite de l'interface et une autre partie qui utilise cette représentation abstraite pour instancier les objets à la demande. Seule la première partie "voit" le XML. Si passer à JSON ou tout autre chose intéressait quelqu'un, il lui serait tout à fait possible d'écrire un parseur JSON qui traduise le JSON dans la représentation abstraite utilisée par StkBuilder. Ceci dit, ce n'est vraiment pas une priorité ;)
  • # Erreur dans le XML

    Posté par (page perso) . Évalué à 2.

    Il y a une erreur dans le XML, il manque la fin: Les deux tags object et class ne sont pas refermés. Il fallait lire:


    <class name="HelloView" parent-class="StkView" title="Hello View">
        <object class="StkFlowContainer" backed-on="flow" />
            <object class="StkLabel" text="Enter your name: " backed-on="txtLbl" />
            <object class="StkEntry" backed-on="nameEntry" />
            <object class="StkLabel" backed-on="welcomeLbl" />
            <object class="StkButton" backed-on="okBtn" label="Ok" navigate="false" mix-replace="false" />
        </object>
    </class>
  • # Très bonne idée !

    Posté par . Évalué à 2.

    Personnellement je découvre vraiment cette années les conteneurs de servlets/serveur d'application java, ainsi que les technologies apparentés. C'est lourd mais amusant je trouve.

    Ce qui serait bien (j'ai pas regardé le site du projet) c'est de travailler aussi sur la partie persistance : le principe de data source et les ORM (je pense que ce dernier point doit déjà être implémenté en Vala).

    Pour ce qui est du tiers présentation je n'ai pas regardé plus que ça les possibilités mais JSF me semble être une bonne idée. C'est ce que j'utilise et c'est vraiment agréable.

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Très bonne idée !

      Posté par (page perso) . Évalué à 3.

      Pour le moment, il n'y a absolument pas d'API de persistance intégrée. A ma connaissance, il existe Catalina, qui est une API de persistance pour GObject. Par contre je n'ai pas vraiment testé, et le peut de code d'exemple que j'ai regardé ne m'a pas spécialement enthousiasmé.

      Depuis le début, Blitzen à été pensé comme un serveur d'application complet, avec une API de persistance. Je n'en ai jamais parlé jusque là, car je n'ai pas envie de créer une attente que je ne pourrai pas satisfaire. Blitzen est actuellement un one-man project et il ne grandira peut être jamais assez pour supporter tout ce que j'ai envie d'y implémenter. J'avance donc petit à petit, suivant le temps libre que je peux y consacrer. J'ai toujours vraiment envie d'écrire un moteur de persistance pour Blitzen, en C/GObject, et j'ai même commencé un draft. Mais ça ne sera pas disponible en release avant assez longtemps. Si cela sort un jour, ça s'appellera "dasher". C'est vraiment tout ce que je peux en dire pour le moment.
      • [^] # Re: Très bonne idée !

        Posté par (page perso) . Évalué à 1.

        s/peut/peu/
      • [^] # Re: Très bonne idée !

        Posté par . Évalué à 2.

        J'imagine bien. Je ne peux pas t'aider, mais je trouve vraiment que ton idée de faire un serveur d'application pour Vala est une excellente idée. Bon courage et bonne chance !!

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

  • # Blitzen?

    Posté par . Évalué à -7.

    Bravo! Encore un langage, avec ses règles et syntaxes propres, je suppose...
    Y avait déjà HTML, CSS, PHP, Javascript, Ajax, etc... tous plus "bricolés" les uns que les autres en fonction des besoins du moment de leur auteur.
    Est-ce pour justifier la fonction de webmaster ?
    Un peu (beaucoup) marre de ces empilements...totalement inutiles, totalement trompeurs, totalement pervers (1), vu la stupidité des sites commerciaux, ou vendus au commerce.
    5 (cinq) langages (+ les pseudo-langages wordpress, joomla, spip ou autres) ça fait au minimum 6 pour diffuser mon texte ou mes 3 photos, sans RIEN maîtriser de la façon dont c'est fait. MARRE !!!

    (1) je n'ai jamais vu, par exemple, un site paginé sans "ascenseur" (ô merveille qui m'oblige à viser avec précision une cible de 5x5pixels, puis tout en faisant glisser ma souris d'une main en prenant bien garde de ne pas lâcher le bouton, en la faisant glisser donc en suivant attentivement de l'autre main le texte sur l'écran, lequel évidemment tressaute sous la manoeuvre, jusqu'à obtenir approximativement la suite, mais dans l' effort j'ai quasi oublié où j'en étais). Sans AUCUN doute, c'est possible en flash-javaframeworkmachin-ajaxtruc-HTMLchose-CSSversionbricol...

    Il est vrai que mon pseudo indique mon état, mais pas mon état d'indignation...
    • [^] # Re: Blitzen?

      Posté par . Évalué à 3.

      Tu suppose mais en fait tu sais pas, c'est là qu'est le problème. Premièrement ce n'est pas un nouveau langage. Vala existe depuis longtemps maintenant, c'est un framework.

      Un serveur d'application c'est fait pour qu'avec un seul langage tu conçoive ton site de A à Z. C'est justement fait pour s'abstraire des technologies sous-jacentes.

      Faire du web c'est mal et franchement depuis que j'en fais avec JSF (mais c'est pareil avec GWT par exemple) je respire, parce que je code tout en Java, plus de prise de tête à devoir jongler entre je ne sais combien de langages. Même la partie persistance est en java (avec l'ORM et (H|JP)QL).

      Après il est claire que ce n'est pas fait pour faire de la performance mais quand on utilise PHP/perl/python/ruby c'est certainement pas fait pour obtenir des benchmarks de folies.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: Blitzen?

        Posté par (page perso) . Évalué à 0.

        Berk, GWT c'est créer des applications qui ne devraient pas être dans un navigateur, mais être de vraies applications. C'est énervant cette mode de faire tout et n'importe quoi sur le Web.

        DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: Blitzen?

          Posté par . Évalué à 1.

          Oui est non. GWT ça sert juste à créer du HTML/javascript. Tout ce qui peut être fais en GWT ça peut très bien se faire avec n'importe quel CGI. Je trouve que la dérive ce situe surtout dans d'autres choses comme la 3D dans un navigateur, la transformation à la volée de musique, etc.

          Pour GWT c'est juste un problème d'utilisation du framework, mais il ne permet ni plus ni moins que ce qui se faisait avant, ça n'est là que pour simplifier (au même titre que simphony, rail ou django).

          Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Blitzen?

      Posté par . Évalué à 4.

      > Y avait déjà HTML, CSS, PHP, Javascript, Ajax, etc... tous plus "bricolés" les
      > uns que les autres en fonction des besoins du moment de leur auteur.

      Ajax n'est pas un langage.

      En fait il faudrait séparer en catégories.

      * HTML c'est pour le contenu
      * CSS c'est pour le rendu du contenu
      * Javascript c'est pour la logique côté client

      Chaque catégorie est nécessaire et normalisée, il n'y a rien de bricolé. Après tu
      as les serveurs applicatifs qui permettent de rendre ça et qui ont une couche
      d'abstraction plus (Blitzen ou les divers frameworks) ou moins (PHP) importante.
    • [^] # Re: Blitzen?

      Posté par . Évalué à 2.

      Pour ton histoire d'ascenseur, ça n'a juste rien a voir avec le langage utilisé. Mais tu peut utiliser un bon navigateur aussi, de ceux qui te donnent plus de choix :
      - flèche vers le bas pour descendre un peu
      - espace pour descendre d'un écran
      - possibilité d'activer le défilement doux pour que le texte de « saute » pas
      - probablement tout un tas d'extension qui le permettent

      Tu cris aussi contre OOo/LibreOffice parce que le format A4 est pas adapté à ton écran ou que quand tu fait un document sur plusieurs pages tu as le même problème, ou contre ton lecteur de PDF ? Tu utilise la ligne de commande ou tu utilise un explorateur de fichier qui lui non plus n'arrive pas à afficher tout tes fichiers et t'oblige à avoir un ascenseur ? Dans un shell aussi tu as un ascenseur quand la sortie de ta commande est trop grande par exemple.

      Bref crier c'est bien proposer c'est mieux.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Blitzen?

      Posté par . Évalué à 5.

      obvious troll is obvious
  • # suite

    Posté par . Évalué à -1.

    Ceci dit, j'ai rien contre Blitzen, et pour cause!

Suivre le flux des commentaires

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