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.
Aller plus loin
- Le site du projet (6 clics)
- L'annonce de sortie (1 clic)
- Le tarball (sources+doc+demo+tuto) (6 clics)
- Le manuel avec un tutorial (4 clics)
- Du code d'exemple (1 clic)
# Harmonisation
Posté par ZankFrappa . Évalué à 4.
Ça pourrait être bien de regrouper autant que possible vos différents travaux non ?
[^] # Re: Harmonisation
Posté par Samos . Évalué à 5.
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 Samos . Évalué à 2.
<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 barmic . Évalué à 2.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Très bonne idée !
Posté par Samos . Évalué à 3.
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 Samos . Évalué à 1.
[^] # Re: Très bonne idée !
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Blitzen?
Posté par vieuxcon . Évalué à -7.
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 barmic . Évalué à 3.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Blitzen?
Posté par DLFP est mort . Évalué à 0.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Blitzen?
Posté par barmic . Évalué à 1.
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).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Blitzen?
Posté par tesiruna . Évalué à 4.
> 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 barmic . Évalué à 2.
- 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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Blitzen?
Posté par Gniarf . Évalué à 5.
# suite
Posté par vieuxcon . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.