Valse

Pour le fait que le projet ne sois pas sur GitHub, je te laisse lire cet article qui explique mon choix.

Ensuite, Wala est en effet dans le même projet que Valse. Mais les séparer serait assez simple : il suffirait de les build en deux packages différents. Intégrer un autre moteur de rendu est déjà possible assez facilement. Il suffit de le mettre dans une classe qui implémente Valse.RenderEngine. Ensuite si l'utilisateur veut prendre ce moteur il faut qu'il utilise ce code.

1

Router.options.render_engine = new SuperMoteurDeRendu ();

En tout cas merci de ton retour.

(Re) Bonjour tout le monde !

Je viens de terminer la fameuse boucle {{ for }} qui nous bloquait depuis … le début du projet en fait. Pour l'utiliser, il vous faudra faire quelque chose comme ce qui suit.

Model

1
2
3
4
5
6
7

using Valse;

public class Author : Object {
    public string name {get; set; default = "Clem";}

    public Many<string> articles {get; set; default = new Many<string>.from_array ({"Bienvenue sur mon blog", "Mon premier vrai article", "Utilisez la boucle for dans Wala"});}
}

View

1
2
3
4

{{ for article in mod.articles }}
    <li>{{ article }}</li>
{{ endfor }}
</ul>

Pour faire le pont entre les deux, il vous faudra juste un controlleur qui crée une nouvelle instance de Author et l'envoie dans la vue.

D'ailleurs je suis un boulet, et je n'ai pas mis la bonne syntaxe pour la boucle qui devrait plutôt être encadrée par des {% %}.

Pour le moment, Many ne supporte que les string et les int, mais je devrais rapidement ajouter le support pour à peu près n'importe quel type. Cette classe servira aussi à gérer les relations dans la BDD.

Vous pouvez également utiliser des variables de la forme mod.articles[0], si vous en avez besoin.

De son côté Wizix avance sur les modèles multiples, mais je me suis mal débrouiller avec git, et on va avoir quelques conflits sur les bras …

Bonjour les agrumes !

On se retrouve pour le petit compte rendu journalier. La première nouveauté est que la boucle for supporte les objets (uniquement les propriétés de type string, mais on va améliorer ça). Vous pourrez donc faire quelque chose comme ceci.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

// Les modèles
using Valse;

public class HomeModel : Object {
    Many<UserModel> users {get; set; default = new Many<UserModel>.from_array ({
        new UserModel ("Clem", "clem@zestedesavoir.com"),
        new UserModel ("Truc", "truc@gmail.com"),
        new UserModel ("Bidule", "bidule@openmailbox.org")
    });}
}

public class UserModel : Object {

    public UserModel (string nom, string mail) {
        this.name = nom;
        this.email = mail;
    }

    public string name {get; set;}

    public string email {get; set;}
}

1
2
3
4
5
6
7
8

<!-- La vue -->
<h1>Liste des membres</h1>
<p>Le site compte actuellement {{ mod.users.count }} membres !<p>
<ul>
{{ for user in mod.users }}
    <li><a href="mailto:{{ user.email }}">{{ user.name }}</a></li>
{{ endfor }}
</ul>

Vous obtiendrez alors ce résultat (à condition de passer un HomeModel à votre vue bien entendu).

La seconde nouveauté est la possibilité d'avoir un template général réutilisable facilement sur toutes les pages. Pour utiliser un template, il vous faudra au moins deux vues différentes : le template lui-même et la/les vue(s) qui l'utilise(nt).

1
2
3
4
5
6
7
8

<!-- template.wala -->
<h1>Mon super site - {% zone title %}</h1>

{% zone main %}

<footer>
    <p>Bla, bla, bla ...</p>
</footer>

1
2
3
4
5
6
7
8

<!-- page.wala -->
{% extends 'template.wala' %}

{% zone title %}Une page vraiment bien{% endzone %}

{% zone main %}
<p>Là c'est le corps de la page, où normalement il y a des truc trop bien d'écrits et tout ...</p>
{% endzone %}

Wala fera alors une sorte de combinaison des deux pages, pour obtenir de code.

1
2
3
4
5
6
7

<h1>Mon super site - Une page vraiment bien</h1>

<p>Là c'est le corps de la page, où normalement il y a des truc trop bien d'écrits et tout ...</p>

<footer>
    <p>Bla, bla, bla ...</p>
</footer>

L'avantage est bien-sûr que vous n'aurez pas à faire des copier/coller de toutes les parties qui reviennent sur chaque page de votre site, comme le header ou le footer.

J'ai aussi ajouté une page par défaut qui s'affiche si on lance le serveur lorsqu'aucun controlleur n'a été enregistré.

Voilà, c'est tout pour aujourd'hui !

Bonjour tout le monde ! Ça faisait longtemps.

Petit changelog des quelques nouveautés que j'ai pu ajouter depuis la dernière fois. Il n'y a pas eu des tonnes de changement durant cette semaine, parce que Wizix et Folaefolc ont de nouveau cours, et que je ne suis moi-même en vacances que depuis aujourd'hui.

La première nouveauté est la minification du HTML. Votre code HTML sera minimisé par Wala, si vous avez défini la valeur Router.options.minify = true;, qui est la valeur par défaut.

La seconde nouveauté est plus technique. J'ai mis en place (après de nombreux efforts et commits, qui ont fait que c'est aujourd'hui est le jour où le projet a reçu le plus de commits) un petit script Ruby qui nous dit à quel point le code est propre. Vous pouvez admirer les résultats ici, dans la colonne Coverage. Et si jamais vous voudriez intégrer ce script sur votre projet, cadeau.

Et comme je suis en vacances, le projet devrait redevenir actif dans les jours qui suivent !

Bonjour à tous.

Encore un petit compte-rendu de l'évolution du projet. Il ne s'est pas passé grand chose depuis la dernière fois, mais j'ai tout de même réussi à fixer un bug assez génant qui faisait que certaines variables dans les vues étaient mal ou pas interpétés. C'était dû à une mauvaise utilisation des Regex de ma part.

Maintenant, je travailles sur la compression des fichiers avec Gzip. Seulement je me demande si c'est réellement pertinent. À terme, Valse serait en effet utilisé avec Nginx ou Apache, le serveur libsoup interne ne servant plus qu'à pouvoir développer rapidement des sites web, sans avoir à installer des logiciels supplémentaires.

Or ces serveurs prennent en charge Gzip, et donc je me demandes si c'était vraiment utile de l'utiliser dans ce qui sera le serveur de test de Valse ? Qu'est-ce que vous en pensez ?

Salut,

je suis le projet depuis ces débuts. Et pour répondre à t'a questions : Non inutile de l’implémenter pour 2 raisons :

• La première c'est déjà dans le noyau Linux.
• La deuxième c'est que GZIP n'est pas le meilleur qui existe regarde le LZ4

Sinon t'on projet et très intéressant. Bonne continuation.

En fait je ne pensait pas à réécrire l'algorythme de Gzip, mais à l'utiliser via les APIs disponibles en Vala, pour compresser les fichiers avant de les envoyer aux clients. J'ai pas dût être clair dans mon message, je vais éditer.

En tout cas, merci de ton soutien !

Bon, puisque qu'il n'y a pas plus d'avis que ça, je vais faire ce qui me semble le plus logique, c'est-à-dire, ne pas utiliser Gzip. J'ai chosi de faire ça tout simplement parce que à terme le serveur libsoup interne ne devra plus servir qu'à des tests, et que Valse devra être couplé à Nginx ou Apache pour fonctionner en «production».

Bonjour à tous !

Le projet n'avance pas très vite, malgré mes vacances, mais on se rapproche doucement de l'alpha 2. J'ai récemment ajouté le support des dates dans la base de donnée, qui pourront être utilisé grâce à la classe DateTime standard.

J'ai aussi amélioré le jeu de tests, ce qui m'a permis de remarquer que la méthode DataBase.all était cassée. Il faut que je me penche dessus, mais ça ne sera pas dans l'alpha 2.

Je vais aussi ajouter le support des dates dans Wala. Je penses le faire comme ça.

1
2
3
4
5
6
7
8
9

{{ mod.une_date.year }}
{{ mod.une_date.month }}
{{ mod.une_date.day }}
{{ mod.une_date.hour }}
<!-- etc -->
{{ mod.une_date.natural }}
<!-- donnerai par exemple 
  Jeudi 23 mars 2079 à 10:33
-->

Je ne sais pas si ça vous conviens, ou si vous avez des idées d'amélioration. Si c'est le cas, n'hésitez pas à m'en faire part !

Je comprends mal comment fonctionnerait ton pattern. Dans ma tête ce ne sera pas pratique à utiliser, mais j'ai probablement mal compris, tu pourrais l'expliquer ?

Imaginons que tu ai un modèle comme celui-ci.

1
2
3
4
5

public class User : Object {
    public string name {get; set;}

    public DateTime register_date {get; set;}
}

Tu le passe ensuite à ta vue. Wala génère alors tout plein de variables utilisables dans ta vue, comme mod.register_date.year pour l'année de la date, mod.register_date.month pour son mois, et ainsi de suite pour le jour, l'heure, les minutes, les secondes.

Tu aurais aussi une variable mod.register_date.natural qui te donnerai la date de manière "naturelle", comme par exemple Mercredi 12 Juin 1578 à 13:07.

Par exemple, si ta date est celle du 20 Avril 2003 à 5 heures et 54 minutes, tu pourrait faire …

1

<p>Depuis {{ mod.ma_date.year }}</p>

Tu aurais alors …

1

<p>Depuis 2003</p>

J'espère que c'est clair maintenant.

Beaucoup plus, merci.

Par exemple faire quelque chose comme …

1
2

{{ mod.date('d/m/Y') }}
<!-- Donnerai 03/12/2006 -->

C'est une bonne idée en effet. Je pense que je vais faire ça. Merci de l'idée.

Bonsoir !

Je ne vous en avait pas encore parlé, mais j'ai amélioré le routage. Avant ça, vous pouviez récupérer une seule partie de l'URL après l'action et le controlleur. Par exemple vous pouviez aller sur /forums/sujet/5573/ et récupérer l'identifiant 5573 grâce à req.query_id. Sauf que pour des URLs comme /forums/sujet/5573/valse, c'était impossible de récupérer la partie valse.

Maintenant, vous pouvez le faire. Pour cela, il faudra utiliser une action complexe/complète (il faudrait que je tranche un jour …), et lors de son enregistrement, il faudra préciser qu'elle supporte certains paramètres.

1

this.add_complete_action ("sujet", sujet, {"id", "nom"});

Ici, id et nom sont les deux paries "optionelles" de l'URL, dans l'ordre où ils seront donnés.

Ensuite vous pourrez les récupérer dans votre action, à l'aide de req.query_ids.

1
2
3
4
5

public Response sujet (Request req, Response res) {
    int id = int.parse (req.query_ids["id"]);
    var sujet = db.get_id<Sujet> (id);
    return page ("sujet.wala", sujet);
}

Dans cet exemple, récupérer le slug du sujet n'a pas beaucoup d'intérêt, puisque l'id suffit. Mais certains blog (ou autre) utilisent des urls comme articles/23/commentaires/page/2. Tout de suite, ça devient beaucoup plus intéressant.

Et pour vous teaser un peu sur la suite, je travaille sur l'implémentation de SimpleCGI. Pour ceux à qui ça ne dit rien, c'est un protocole utilisé entre un serveur web et une application comme un site écrit avec PHP ou Valse, qui leur permet de communiquer. Ainsi vous serez en mesure d'héberger un site web créé avec Valse chez n'importe quel hébergeur proposant un serveur Apache ou Nginx.

Bonsoir tout le monde.

Vous serez (peut-être) heureux d'apprendre que je viens de terminer l'implémentation de SimpleCGI. J'y aurai passé pas mal de temps, mais maintenant, le code est beaucoup plus propre qu'avant, et on n'est plus dépendants de libsoup (bon on a gagné une autre dépendance, celle de libscgi, mais elle me gène moins).

Tout d'abord, il vous faudra maintenant un serveur web en plus de Valse. Je vous recommande Nginx puisque c'est celui-ci que j'ai utilisé pour débugger, et donc celui qui marchera le mieux. Bon, il y a aussi un aspect un peu plus négatif, mais il devrait bientôt être fixé : l'upload de fichier ne fonctionne plus (les formulaires normaux marchent quand même).

Il faudra donc aussi configurer le serveur web. Je vous donne le fichier nginx.conf que j'utilise avec Valse.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#user  nobody;
worker_processes  1;

error_log  logs/error.log;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    sendfile        on;

    keepalive_timeout  65;

    server {
        listen       80;
        server_name  localhost;

        location / {
            include D:/nginx/nginx-1.8.1/conf/scgi_params;
            scgi_read_timeout 60s;
            scgi_pass localhost:9000;
        }

    }

}

Il ne me reste plus qu'une seule issue avant l'alpha 2 !

Tu as retiré la possibilité de faire un serveur standalone, du coup ? Ça paraît un peu dommage, c’est bien pratique en période de dev.

J'ai préféré oui. Si je laissait ce serveur, ça voulait dire que je devais limite dupliquer le code du routeur, et une bonne partie de celui de la classe Request. Comme je voulais me débarasser de libsoup de toute façon, j'en ai profité. Mais après je pourrais toujours faire un programme du style WAMP/LAMP/MAMP qui installe Ngninx, Sqlite et Valse et permet de les gérer.

Bonjour à tous.

Je passe juste pour vous signaler que le projet n'est pas mort. Je réalisais le site de Valse, et après avoir tapé deux ou trois tutoriels en HTML pur, je me suis dit que ça serait sympa de pouvoir utiliser du MarkDown à la place. Sauf que la seule bibliothèque qui permet de faire ça en Vala n'est pas compatible Windows.

J'ai donc décidé de créer ma propre bibliothèque pour cela. Et je me suis que tant qu'à réinventer la roue, autant le faire bien : je vais utiliser un MarkDown proche de celui de ZdS, extensible et évidemment compatible Windows. Seulement là aussi j'ai rencontré une situation inconfortable : l'autocomplétion du Vala dans Atom (l'éditeur de code que j'utilise) est juste horrible.

Je me suis donc lancé dans la création d'un package, joliement nommé super-vala (vous sentez l'inspiration ? ). Pour le moment, c'est assez expérimental, mais je commence à avoir quelque chose d'assez intéréssant.

Bref. J'ai deux nouveaux projets sur les bras. Peut-être qu'ils ne seront jamais utilisables, peut-être que je les présenterai sur ZdS un jour … En tout cas, je voulais vous dire que je n'abandonnais pas Valse, que j'étais juste sur d'autres projets "liés" pour le moment.