blog.pagesd.info

ASP.NET MVC 2 : Des helpers HTML fortement typés

Michel — Sat, 31 Jul 2010 18:26:00 +0200

Ceci est la traduction du billet "ASP.NET MVC 2: Strongly Typed Html Helpers" de Scott Guthrie.

Ceci est le premier billet d'une série consacrée à la prochaine sortie de ASP.NET MVC 2. Ce billet présente les nouveaux helpers fortement typés qui ont fait leur apparition dans ASP.NET MVC 2.

Les helpers HTML actuels

ASP.NET MVC 1 est fourni avec un certain nombre de helpers HTML que vous pouvez utiliser dans les vues pour simplifier la génération de l'interface utilisateur en HTML. Par exemple, pour afficher une textbox, vous pouvez utiliser le helper Html.TextBox() de la façon suivante dans une de vos vues :

Le premier paramètre de la méthode helper ci-dessus fournit le nom et l'id pour la textbox et le second paramètre défini la valeur qu'elle doit contenir. Ce helper aura comme effet de produire le code HTML suivant :

Les nouveaux helpers HTML fortement typés

Une des fonctionnalités qui nous a le plus été demandée était de gérer des helpers HTML fortement typés basés sur des expressions lambda pour référencer les objets Model ou ViewModel passés aux vues. Cela permet une meilleure vérification des vues au moment de la compilation (et donc de découvrir les bugs lors de la programmation et pas de l'exécution) et aussi la possibilité de profiter de l'intellisense dans les vues.

Les nouveaux helpers HTML fortement typés font désormais parti de ASP.NET MVC 2. Ces méthodes utilisent la convention de nommage "Html.HelperNameFor()", comme par exemple : Html.TextBoxFor(), Html.CheckBoxFor(), Html.TextAreaFor()... Ils autorisent l'utilisation d'une expression lambda pour définir en une fois les attributs id/name et la valeur du contrôle à générer.

Par exemple, avec ASP.NET MVC 2, nous pouvons maintenant utiliser le nouveau helper Html.TextBoxFor() en plus du Html.TextBox() classique :

Vous remarquerez dans le code ci-dessus que nous n'avons plus besoin d'utiliser la chaine "ProductName". Les expressions lambda sont suffisamment souples pour permettre de retrouver le nom de la propriété ou du champ dans notre modèle d'objets en plus de sa valeur.

Etant donné que les helpers HTML sont fortement typés, cela nous permet d'avoir accès à l'intellisense de Visual Studio lorsque nous écrivons l'expression lambda :

Le code HTML généré est exactement le même que pour la version présentée dans le premier exemple :

Les helpers HTML fortement typés fournis avec ASP.NET MVC 2

ASP.NET MVC 2 intègre d'ores et déjà les helpers HTML fortement typés suivants :

Eléments HTML

Html.TextBoxFor()
Html.TextAreaFor()
Html.DropDownListFor()
Html.CheckboxFor()
Html.RadioButtonFor()
Html.ListBoxFor()
Html.PasswordFor()
Html.HiddenFor()
Html.LabelFor()

Autres helpers

Html.EditorFor()
Html.DisplayFor()
Html.DisplayTextFor()
Html.ValidationMessageFor()

Je reviendrai sur les nouvelles méthodes helpers Html.EditorFor() et Html.DisplayFor() dans un autre billet de cette série quand j'aborderai les évolutions apportées à la fonctionalité d'auto-scaffold en ASP.NET MVC 2. Nous verrons aussi le helper Html.ValidationMessageFor() dans le prochain billet de cette série qui présentera les nouveautés en matière de validation apportées par ASP.NET MVC 2.

Les helpers HTML fortement typés et le Scaffolding

VS 2008 et VS 2010 utilisent désormais tous les deux les nouveaux helpers fortement typés pour auto-générer les vues fortement typées à partir de la commande "Add View".

Par exemple, supposons que nous ayons une classe "ProductsController" toute simple comme ci-dessous avec une action Edit() qui renvoie un formulaire de modification pour un objet "Product" :

Dans Visual Studio, nous pouvons faire un clic-droit à l'intérieur de l'action Edit() et choisir la commande "Add View" dans le menu contextul pour créer une nouvelle vue. Nous choisirons de créer une vue selon le modèle "Edit" qui sera basée sur un objet de type "Product" :

Avec ASP.NET MVC 2, la vue qui a été créée par défaut utilise désormais les nouveaux helpers HTML fortement typés pour faire référence à l'objet Product :

Conclusion

Les helpers HTML fortement typés intégrés avec ASP.NET MVC 2 fournissent une méthode pratique pour obtenir un contrôle du type de données à l'intérieur de nos vues. Ils permettent un meilleur contrôle de nos vues dès la compilation (ce qui vous permet de détecter les erreurs à la compilation et pas à l'utilisation) et ils offrent un support de l'intellisense plus puissant lorsque vous codez vos vues depuis Visual Studio.

Ceci est la traduction du billet "ASP.NET MVC 2: Strongly Typed Html Helpers" de Scott Guthrie.

Blogmarks du 28/07/2010

Michel — Thu, 29 Jul 2010 10:35:00 +0200

Git Reference : Un petit site pour apprendre et mémoriser rapidement les principales commandes de Git (et les plus utilisées)

git

Création d'un premier projet avec Sinatra

Michel — Wed, 28 Jul 2010 19:45:00 +0200

Après avoir brillamment suivi pas à pas mon premier tutoriel pour installer Ruby et Sinatra sur mon PC Windows 7, je continue sur ma lancée avec la réalisation du deuxième tutoriel proposé par Darren Jones.

Le but de ce tutoriel est de programmer une première application très très simple qui va se contenter d'afficher un texte à l'envers, d'où son nom : Projet 1 : Reverse. A travers cette mini-application, on peut déjà apprendre quelques trucs sur le fonctionnement de Sinatra, voire sur Ruby si on débute comme moi.

C'est parti

Pour commencer, j'ai créé un répertoire C:\Ruby\projets\reverse puis un fichier main.rb à l'intérieur :

require 'rubygems'
require 'sinatra'

get '/' do
  "I did it my way!"
end

Toutes les applications Sinatra ont besoin des deux premières lignes. Il y a ensuite une ligne blanche pour faire plus joli puis 3 lignes de code où se situe toute l'action :

«get» indique quelle méthode HTTP on souhaite gérer : un GET dans le cas présent,
«'/'» correspond à la route à gérer, soit la racine de l'application dans ce cas,
«do ... end» est un bloc de code pour définir ce qui se passe quand quelqu'un demande la racine du site.

La dernière ligne à l'intérieur du bloc «do ... end» contient toujours (je pense) ce qui sera affiché dans la page, soit "I did it my way!" dans ce premier exemple.

Pour tester ce code, on peut directement double-cliquer sur le fichier main.rb dans le répertoire C:\Ruby\projets\reverse ou faire ça à la main dans une invite de commande :

C:\Ruby\projets\reverse>ruby main.rb

Et Sinatra entre en scène :

== Sinatra/1.0 has taken the stage on 4567 for development with backup from WEBrick
[2010-07-27 21:44:57] INFO  WEBrick 1.3.1
[2010-07-27 21:44:57] INFO  ruby 1.9.1 (2010-07-02) [i386-mingw32]
[2010-07-27 21:44:57] INFO  WEBrick::HTTPServer#start: pid=3604 port=4567

On peut alors lancer un navigateur pour appeler l'URL http://localhost:4567/ :

Tant qu'on est là, si on essaie d'aller sur une URL qui n'existe pas, comme http://localhost:4567/reverse, on obtient alors la page d'erreur 404 de Sinatra pour indiquer qu'il ne connait pas ce morceau :

Cette page d'erreur nous conseille même sur la route ajouter dans notre fichier pour que cela fonctionne, en l'occurrence :

get '/reverse' do
  "Hello World"
end

Avec Sinatra, c'est pas plus compliqué que ça pour créer des actions correspondant à différentes routes.

Ajouter une vue

Pour l'instant, on va rester sur notre route «'/'» et essayer de faire un peu mieux que de seulement renvoyer une ligne de texte. Pour cela, il faut créer une vue en modifiant le fichier main.rb de la façon suivante :

require 'rubygems'
require 'sinatra'

get '/' do
  erb :home
end

__END__

@@ home

<h1>Reverse</h1>

<p>Welcome to the home page of my very first Sinatra app.</p>

Ce coup-ci, au lieu d'utiliser la dernière ligne du bloc pour dire à Sinatra ce qu'il doit afficher, nous lui avons demandé d'utiliser la vue "home" que nous avons codé en erb (embedded ruby). Cette vue est enregistrée à la fin du fichier, après la ligne __END__ et elle est repéré par le code @@ home.

Pour voir ce que donne cette vue, il faut revenir à l'invite de commande et arrêter le serveur s'il est toujours en cours d'exécution. Ctrl-C =>Sinatra has ended his set (crowd applauds). Puis on relance le serveur avec ruby main.rb et on réaffiche la page http://localhost:4567 :

Créer une vue externe

En fait, on n'est pas obligé de stocker les vues dans le même fichier. Il est bien plus pratique de les enregistrer dans un sous-répertoire "views" de notre projet (soit C:\Ruby\projets\reverse\views dans mon cas).

Là, il suffit de créer le fichier "home.erb" avec le code ci-dessous :

<h1>Reverse</h1>

<p>Welcome to the home page of my very first Sinatra app.</p>

Il est alors possible de simplifier le fichier "main.rb" de la façon suivante :

require 'rubygems'
require 'sinatra'

get '/' do
  erb :home
end

Il ne reste plus qu'à contrôler que tout est ok : Ctrl-C, ruby main.rb, rafraichir la page et vérifier que rien n'a changé.

Créer un layout

D'un point de vue visuel, on peut faire encore mieux en définissant un "layout" qui servira de gabarit pour englober toutes les vues. Cela permet d'éviter de répéter le même code dans toutes les vues de l'application.

Pour cela, on doit juste créer un fichier "layout.erb" dans le sous-répertoire "views" et y saisir le code html ci-dessous :

<!DOCTYPE html>
<html lang="en">
<head>
<title>Reverse!</title>
<meta charset=utf-8 />
</head>
<body>
<h1>Reverse</h1>

<%= yield %>

<p>The first Sinatra project for I Did It My Way</p>
</body>
</html>

Tout ce code html sera toujours affiché à chaque fois qu'une vue sera affichée, à part la ligne <%= yield %> qui sera remplacée par le contenu spécifique de la vue.

Ainsi, si on modifie légèrement le code de la vue "home.erb" :

<h2>Home</h2>
<p>Welcome to the home page. This app is going to be amazing....</p>

Le fait de relancer le serveur et de ré-afficher l'URL http://localhost:4567 doit donner le résultat suivant :

Comme vous pouvez le constater, le sous-titre "Home" et le message "Welcome..." en provenance de la vue "home.erb" apparaissent entre le titre "Reverse" et le paragraphe "The first app...", soit exactement là où se situait la ligne <%= yield %> dans le fichier "layout.erb".

ERB

La balise <%= yield %> est un exemple d'embedded ruby (ou erb en abrégé). On peut ainsi ajouter du code ruby dans les fichiers html en l'insérant à l'intérieur de blocs <% ... %>. C'est très utile dans le cas de conditions if :

<% if something_happens %>
<h1>Something happened</h1>
<% else %>
<h1>Nothing happend</h1>
<% end %>

Si le code ruby est placé dans un bloc <%= ... %>, alors ce code est évalué et son résultat est affiché. Comme par exemple dans le code suivant :

<% title = "Reverse" %>
<h1>
<%= title %>
</h1>

Le premier bloc de code <% ... %> défini une variable appelée "title" et le second bloc de code <%= ... %> évalue cette variable et affiche sa valeur. Même si cet exemple est ultra simple, dans la vrai vie on peut faire des tas de chose très utile grâce à l'embedded ruby.

Définir une variable

Plus concrètement, nous allons utiliser embeded ruby pour définir le titre de notre page. Dans un premier temps, on met à jour le code de "main.rb" :

require 'rubygems'
require 'sinatra'

get '/' do
  @title = "Home"
  erb :home
end

Celui-ci initialise une variable session nommée @title (c'est une variable session parce que son nom débute par un @). Les variables session sont disponibles dans les autres parties du code, y compris dans les vues. On peut donc maintenant faire référence à notre variable session @title dans notre vue ou même notre layout.

Par conséquent, nous pouvons modifier "layout.erb" pour qu'il utilise notre variable session :

<!DOCTYPE html>
<html lang="en">
<head>
<title>Reverse!</title>
<meta charset=utf-8 />
</head>
<body>
<h1>Reverse</h1>
<h2><%= @title %></h2>

<%= yield %>

<p>The first Sinatra project for I Did It My Way</p>
</body>
</html>

Puis nous pouvons alors supprimer le titre qui était en dur dans la vue "home.erb" :

<p>Welcome to the home page. This app is going to be amazing....</p>

Par acquit de conscience, on peut redémarrer le serveur et contrôler que rien n'a changé, ce qui signifie que notre variable session a bien été prise en compte et que nous pouvons maintenant définir le titre de la page au niveau de l'action.

On va vérifier cela en créant une nouvelle route dans le source "main.rb" :

require 'rubygems'
require 'sinatra'

get '/' do
  @title = "Home"
  erb :home
end

get '/frank' do
  @title = "My Way"
  erb :home
end

Après avoir encore une fois redémarré le serveur, on peut aller à la page http://localhost:4567/frank pour constater que le sous-titre n'est plus "Home" mais "My Way" :

Mais on continue à voir presque la même chose, étant donné qu'on utilise la même vue dans les deux cas. On va donc créer une vue différente qui s'affichera pour la route "/frank". Pour cela, on saisi le code suivant dans un fichier "frank.erb" à créer dans le sous-répertoire "views" :

<p>
And now, the end is here
And so I face the final curtain
My friend, I'll say it clear
I'll state my case, of which I'm certain
I've lived a life that's full
I traveled each and ev'ry highway
And more, much more than this, I did it my way
</p>

Il faut aussi changer la ligne erb:home par erb:frank dans le cas de la route "/frank" avant de redémarrer le serveur et de ré-afficher la page http://localhost:4567/frank pour voir ce que cela donne.

Poster quelque chose

Jusqu'à présent on n'a pas fait grand chose d'autre que des pages statiques. Mais quand on crée une application web, c'est quand même pour avoir un peu d'interaction avec le visiteur. On va donc rendre les choses un peu plus intéressante en commençant par créer un formulaire dans notre page d'accueil. Pour cela, on remplace tout le code de "home.erb" par le code suivant :

<form action="/reverse" method ="post" accept-charset="utf-8">
<input type="text" id="phrase" name="phrase" value="Write something...">
<input type="submit" value="...and reverse it!">
</form>

Une fois que c'est fait, on a aussi besoin d'une nouvelle action pour prendre en compte le formulaire lorsqu'il est envoyé. Si vous observez le code html de "home.erb", vous pouvez voir que le formulaire va être posté à l'URL "/reverse" avec une méthode POST.

Normalement, c'est le moment où vous devriez vous rendre compte que la syntaxe de Sinatra est bien faite. Et vous devriez même avoir une idée ce que nous allons ajouter dans le fichier "main.erb" :

require 'rubygems'
require 'sinatra'

get '/' do
  @title = "Home"
  erb :home
end

post '/reverse' do
  params.inspect
end

L'avant-avant dernière ligne (l'antépénultième pour les érudits) défini la nouvelle action qui va gérer la route "/reverse". Cette action est définie pour une route de type POST, ce qui signifie qu'elle ne sera activé que pour une requête POST (ce qui correspond à l'envoi d'un formulaire). Ca c'est bon ? Mais par contre, c'est quoi cette ligne params.inspect ? "params" est une collection qui contient toutes les informations qui ont été envoyées en tant que paramètre (aussi bien à travers un formulaire que via l'URL) Par conséquent, params.inspect affiche les paires clé/valeur correspondantes à tous ces paramètres.

Allez. On relance le serveur, on accède à la page http://localhost:4567/, on saisi une phrase au hasard et on clique sur le bouton [... and reverse it] :

Cela signifie que la clé "phrase" contient la valeur "I Did It My Way". Et nous avons une clé "phrase" parce que le formulaire dans "home.erb" contient une balise input dont l'attribut name est "phrase". Il est possible d'accéder à n'importe quel paramètre stocké dans la collection "params" en employant la syntaxe params[:key]. Par exemple, params[:phrase] renverra "I Did It My Way".

Supposons que l'on ait le formulaire suivant :

<form action="/reverse" method ="post" accept-charset="utf-8">
<input type="text" name="name">
<input type="text" name="email">
<input type="text" name="password">
<input type="submit" value="submit">
</form>

On va pouvoir accéder aux valeurs de ce formulaire en utilisant params[:name], params[:email] et params[:password].

Maintenant que nous savons comment accéder aux données d'un formulaire, nous allons pouvoir faire quelque chose du texte saisi dans notre vue. Pour cela, nous ajoutons le code ci-dessous au fichier "main.rb" :

require 'rubygems'
require 'sinatra'

get '/' do
  @title = "Enter Your text here"
  erb :home
end

post '/reverse' do
  @title = "Here's Your Reversed Text:"
  params[:phrase].reverse
end

On re-démarre le serveur, on ré-accède à la page http://localhost:4567/, on re-saisi une phrase au hasard et on re-clique sur le bouton [... and reverse it]. Cette fois-ci, on doit voir la phrase saisie affichée à l'envers, de la droite vers la gauche :

On obtient ce résultat parce que la dernière ligne de la méthode est params[:phrase].reverse. Et si vous vous souvenez bien, la dernière ligne d'une méthode est ce qui est renvoyé pour l'URL demandée. params[:phrase] correspond au texte entré dans le formulaire et le .reverse à sa suite correspond à la méthode "reverse" pour les chaines de caractères. Et cette méthode fait exactement ce que son nom laisse supposer, soit inverser l'ordre des caractères d'une phrase. Coup de bol, c'est aussi ce à quoi notre application était destinée !

Faire un postback

On peut pousser le bouchon encore plus loin et utiliser la même URL pour nos deux pages (l'affichage du formulaire et l'affichage du résultat de notre application). C'est possible parce que pour afficher le formulaire on fait une requête GET et que pour inverser le texte on envoie le formulaire avec une requête POST. Par conséquent, on peut donc gérer ces deux actions avec la même route, mais deux actions différentes.

On peut donc réécrire "main.rb" :

require 'rubygems'
require 'sinatra'

get '/' do
  @title = "Enter Your text here"
  erb :home
end

post '/' do
  @title = "Here's Your Reversed Text:"
  params[:phrase].reverse
end

Cette fois-ci, l'URL de la route est toujours la même, mais la méthode HTTP est différente (soit un GET, soit un POST). Le fait de poster vers soit-même s'appelle un "postback". En plus du GET et du POST, Sinatra gère les deux autres méthodes HTTP, à savoir PUT et DELETE. Nous n'en avons pas besoin pour cette application, mais nous aurons l'occasion d'y revenir dans un autre projet.

Pour que le postback fonctionne, il faut aussi penser à modifier l'attribut action du formulaire au niveau de la vue "home.erb" pour qu'il pointe vers la même URL :

<form action="/" method ="post" accept-charset="utf-8">
<input type="text" id="phrase" name="phrase" value="Write something...">
 <input type="submit" value="...and reverse it!">
</form>

Et comme pour l'instant le résultat de notre application se présente seulement sous la forme d'une ligne de texte, on va enjoliver ça en créant une nouvelle vue "reverse.erb" qui va nous permettre d'afficher ce résultat de façon un peu plus élégante :

<h3>Here is your reversed text......</h3>
<p><strong><%= @reversed_text %></strong></p>

Il suffit alors de référencer cette vue dans le fichier "main.rb", dans lequel nous initialisons la variable session "@reversed_text" que nous avons utilisée dans notre nouvelle vue :

require 'rubygems'
require 'sinatra'

get '/' do
  @title = "Enter Your text here"
  erb :home
end

post '/' do
  @title = "Here's Your Reversed Text:"
  @reversed_text = params[:phrase].reverse
  erb :reverse
end

Si on relance tout et que l'on fait tout bien comme il faut, on arrive sur l'écran suivant :

Les paramètres nommés

On pourrait en rester là puisque l'application fait ce qui était prévu. Mais on peut faire mieux, comme par exemple permettre à l'utilisateur d'indiquer la phrase qu'il veut inverser directement au niveau de l'URL. OK, mais comment faire pour retrouver le texte qui a été proposé ? Pas compliqué, il faut juste ajouter une route avec un paramètre nommé :

get '/:phrase' do

Cela va ajouter automatiquement un paramètre "phrase" à la collection "params". On retrouvera donc tout ce que l'utilisateur aura indiqué dans l'URL en utilisant params[:phrase]. Par exemple, pour l'URL http://localhost:4567/frank on aura params[:phrase] égal à "frank" et pour l'URL http://localhost:4567/sinatra on aura params[:phrase] égal à "sinatra" .

On va donc compléter notre fichier "main.rb" pour lui ajouter du code destiné à gérer cette route :

require 'rubygems'
require 'sinatra'

get '/' do
  @title = "Enter Your text here"
  erb :home
end

post '/' do
  @title = "Here's Your Reversed Text:"
  @reversed_text = params[:phrase].reverse
  erb :reverse
end

get '/:phrase' do
  @title = "Here's Your Reversed Text:"
  @reversed_text = params[:phrase].reverse
  erb :reverse
end

Voyons voir si ça marche. Tout ce qu'il y a à faire (après avoir relancé le serveur pour la dernière fois), c'est d'appeler l'URL http://localhost:4567/ suivi d'une phrase de votre choix et de vérifier que ce texte s'affiche bien à l'envers, comme dans la copie d'écran ci-dessous :

Voilà c'est fini

Et ainsi se termine le tutoriel consacré à la première application Sinatra proposée par Darren Jones (@daz4126) dont ce billet constitue une traduction très très libre.

Contexte d'une recherche Exalead SDK

Michel — Mon, 26 Jul 2010 16:50:00 +0200

Quoiqu'en dise la documentation, il ne faut surtout pas utiliser la forme :

searchQuery.SearchContext = mon_contexte;

Mais obligatoirement la syntaxe :

searchQuery.AddParameter("C", mon_contexte);

En tout cas avec Exalead one:enterprise 4.6.

Et de deux

Michel — Mon, 26 Jul 2010 13:55:00 +0200

You’ve virtually completed the public-facing portion of SportsStore. (...) The well-separated architecture means you can easily change the behavior of any application piece (e.g., what happens when an order is submitted, or the definition of a valid shipping address) in one obvious place without worrying about inconsistencies or subtle, indirect consequences. You could easily change your database schema without having to change the rest of the application (just change the LINQ to SQL mappings).

Steven Sanderson - Pro Asp.net Mvc V2 Framework

Tout vient à point à qui peut attendre

Michel — Fri, 23 Jul 2010 09:03:00 +0200

In this chapter, you built most of the core infrastructure needed for the SportsStore application. It doesn’t yet have many features you could show off to your boss or client, but behind the scenes you’ve got the beginnings of a domain model, with a product repository backed by a SQL Server database. There’s a single MVC controller, ProductsController, that can produce a paged list of products, and there’s a DI container that coordinates the dependencies between all these pieces. Plus, there’s a clean custom URL schema, and you’re now starting to build the application code on a solid foundation of unit tests.

Steven Sanderson - Pro Asp.net Mvc V2 Framework

Installer Sinatra sous Windows 7

Michel — Thu, 22 Jul 2010 13:47:00 +0200

Je suis tombé sur une super série de tutoriels pour apprendre à utiliser Sinatra. C'est le résultat de la bonne résolution de Daz (Darren Jones) pour l'année 2010 et ça s'appelle I Dit It My Way ou "The Sinatra Songbook Project".

C'est l'occasion pour se mettre à Sinatra et je me suis donc lancé dans l'installation des outils nécessaires à son utilisation, en suivant un des premiers tutoriels : Installing Sinatra.

Installer Ruby sur Windows

il faut commencer par installer Ruby étant donné que ce n’est pas quelque chose de déjà présent sur mon PC. C’est pas compliqué du tout. Il suffit d’utiliser RubyInstaller pour Windows (la façon la plus simple d’installer Ruby sous Windows) qui va s’occuper de tout.

Cliquer sur le gros bouton rouge « Download » sur la page d’accueil
Sélectionner la version la plus récente de RubyInstallers (soit Ruby 1.9.1-p429 à ce jour)
Enregistrer le fichier sur le disque dur (soit dans le répertoire C:\Temp dans mon cas)
Double-cliquer sur C:\Temp\rubyinstaller-1.9.1-p429.exe pour lancer l’installation
Le seul truc un peu important, c’est de demander à faire l’installation dans C:\Ruby (et pas C:\Ruby191 comme le propose l’installeur) et de cocher les choix « Add Ruby executables to your PATH » et « Associate .rb and .rbw files with this Ruby installation ».

L’installation est très rapide et au final on se retrouve avec un répertoire « C:\Ruby » d’une cinquantaine de méga.

Installer Sinatra sur Windows

On entre ensuite dans le vif du sujet qui consiste à installer Sinatra. Pour cela, il faut ouvrir une « Invite de commandes » et aller dans le répertoire « C:\Ruby » et lancer la commande suivante :

C:\Ruby>gem install sinatra

Ce qui donne presque aussitôt :

Successfully installed rack-1.2.1
Successfully installed sinatra-1.0
2 gems installed
Installing ri documentation for rack-1.2.1...
Installing ri documentation for sinatra-1.0...
Updating class cache with 0 classes...
Installing RDoc documentation for rack-1.2.1...
Installing RDoc documentation for sinatra-1.0...

C:\Ruby>

Ca y est, mon PC devrait contenir Ruby + Sinatra !

Créer une première application Sinatra

On va alors pouvoir tester que ça marche en codant notre toute première application Sinatra. Pour cela, il suffit d'ouvrir Notepad pour créer le fichier C:\Ruby\test.rb avec le code suivant :

require 'rubygems'
require 'sinatra'
get '/hi' do
  "I Did It My Way!"
end

Puis on demande à Ruby d’exécuter ce programme :

C:\Ruby>ruby test.rb

Ce qui donne :

== Sinatra/1.0 has taken the stage on 4567 for development with backup from WEBrick
[2010-07-22 12:07:23] INFO  WEBrick 1.3.1
[2010-07-22 12:07:23] INFO  ruby 1.9.1 (2010-07-02) [i386-mingw32]
[2010-07-22 12:07:23] INFO  WEBrick::HTTPServer#start: pid=952 port=4567

Ca marche ! Il ne reste plus qu’à lancer un des navigateurs installé sur le PC pour aller voir ce que donne l’adresse « http://localhost:4567/hi ». Et là, je retrouve bien le message attendu, à savoir « I Dit It My Way ! ».

C’est magnifique ! Tout fonctionne comme prévu. Il n'y a qu'à arrêter l'exécution du programme test.rb par un simple Ctrl-C et se préparer pour la suite des tutoriels...

== Sinatra has ended his set (crowd applauds)
[2010-07-22 12:10:43] INFO  going to shutdown ...
[2010-07-22 12:10:43] INFO  WEBrick::HTTPServer#start done.

Blogmarks du 16/07/2010

Michel — Mon, 19 Jul 2010 10:39:00 +0200

From SVN to Mercurial (in Windows7) : Explications sur la façon de migrer un repository Subversion vers Mercurial

subversion - git - mercurial

Blogmarks du 05/07/2010

Michel — Tue, 06 Jul 2010 14:37:00 +0200

TekPub - MVC Music Store : L'application MVC Music Store refactorisée par Rob Conery dans le cadre de la série consacrée à Entity Framework sur TekPub

mvc - developpement

Data annotation belong to View models

Michel — Fri, 02 Jul 2010 09:43:00 +0200

Personally, my recommendation for people who want strict SoC (like I do) is to use ViewModels and only place the annotations on the view model.

ASP.NET MVC 2 Templates, Part 4: Custom Object Templates, via The Big Boy MVC Series

View models belong to Web-project

Michel — Fri, 02 Jul 2010 09:27:00 +0200

In an ASP.NET MVC application the view models belong to the Web-project, they are not part of the domain model. Usually a view model belongs to a single controller, and its views.

Using AutoMapper to map view models in ASP.NET MVC, via The Big Boy MVC Series

Blogmarks du 29/06/2010

Michel — Wed, 30 Jun 2010 08:19:00 +0200

NUnit Template for ASP.NET MVC 2.0 : Un template pour gérer des projets de test unitaires NUnit dans Visual Studio 2010

.net - mvc - nunit

Activer l'intellisense pour le mapping NHibernate dans Visual Studio

Michel — Wed, 23 Jun 2010 14:51:00 +0200

Pour que Visual Studio propose l'intellisence quand on édite les fichier de configuration ou de mapping de NHibernate, il faut définir la propriété "Schema" pour qu'elle pointe sur le fichier "nhibernate-mapping.xsd" ou "nhibernate-configuration.xsd".

Mais plutôt que de faire ça à la main, il est beaucoup plus simple de référencer ces deux fichiers une bon une fois pour toute au niveau de Visual Studio. Pour cela, il suffit de copier les fichiers "nhibernate-mapping.xsd" et "nhibernate-configuration.xsd" dans le répertoire destiné à contenir les schémas pour Visual Studio. Généralement (en tout cas dans mon cas), ce répertoire est : C:\Program Files (x86)\Microsoft Visual Studio 9.0\Xml\Schemas.

Et c'est tout (à moins qu'il m'ai fallu relancer Visual Studio ?).

Blogmarks du 18/06/2010

Michel — Mon, 21 Jun 2010 10:44:00 +0200

Announcing jQuery Fundamentals: An Open-Source jQuery Training Curriculum : Un petit manuel d'apprentissage pour jQuery mis au point par Rebecca Murphey au fur et à mesure des formations qu'elle donne sur le développement avec jQuery

javascript - jQuery - developpement

Blogmarks du 17/06/2010

Michel — Fri, 18 Jun 2010 08:42:00 +0200

ASP.NET MVC View Best Practices – Keep logic out of your views : Présentation de 4 méthodes différentes pour éviter d'avoir à gérer du code (et en particulier des conditions) dans les vues

.net - mvc

Blogmarks du 09/06/2010

Michel — Thu, 10 Jun 2010 16:17:00 +0200

Architecture Guide: ASP.NET MVC + N-tier + Entity Framework and Many More : Un article très complet qui explique comment architecturer une petite application de gestion de documents en ASP.NET MVC

.net - developpement - mvc

MVC Music Store / Raven DB : StoreManagerController (2° partie)

Michel — Tue, 01 Jun 2010 18:40:00 +0200

Ceci est la traduction du billet "Porting MVC Music Store to Raven: StoreManagerController, part 2", le dernier de la série consacrée au portage de l'application MVC Music Store sous RavenDB par Oren Eini, alias Ayende Rahien.

Le contrôleur StoreManagerController contient encore deux méthodes que nous n'avons pas étudiées. Nous allons devoir les aborder de façon un peu différente.

Est-ce que vous devinez pourquoi ?

C'est parce qu'au départ nous étions d'accord sur le fait qu'il n'y avait aucune raison valable de gérer les artistes en tant que document spécifique. Après tout, il ne s'agit que de données de référence. Sauf que maintenant nous devons y faire référence.

C'est sûr qu'on pourrait créer une série de documents artistes, ce qui faciliterait énormément la migration du code :

Mais je continue à penser que les artistes n'existent pas réellement en tant qu'entité indépendante dans notre modèle. Par conséquent, au lieu de suivre cette voie nous allons plutôt faire une projection.

Nous commençons par définir un index "Artists" à l'aide des requêtes linq map / reduce suivantes :

// map 
from album in docs.Albums
select new { album.Artist.Id, album.Artist.Name }

// reduce 
from artist in results
group artist by new { artist.Id, artist.Name } into g
select new { g.Key.Id, g.Key.Name }

Si vous regardez attentivement ce code, vous pouvez voir que sa fonctionnalité principale est de faire un distinct sur l'ensemble des artistes de tous les albums.

Si bien que maintenant nous pouvons coder nos deux dernières méthodes comme ceci :

Il faut bien comprendre un truc : ça ne coûte rien de faire des requêtes avec Raven, parce que Raven ne permet les requêtes que sur des index et que ces index sont créés en tache de fond, ce qui contribue à rendre les requêtes très rapides.

Et cela remet en cause la façon dont vous allez concevoir votre système et de votre modèle de données. Avec Raven, vous cherchez à axer la plupart de vos traitements sur des index et interroger ces index, parce que c'est ce qui est le moins gourmand.

MVC Music Store / Raven DB : StoreManagerController

Michel — Mon, 31 May 2010 21:46:00 +0200

Ceci est la traduction du billet "Porting MVC Music Store to Raven: StoreManagerController", le douzième de la série consacrée au portage de l'application MVC Music Store sous RavenDB par Oren Eini, alias Ayende Rahien.

La dernière partie du portage de MVC Music Store sous Raven concerne toute la partie administration, implémentée au niveau du contrôleur StoreManagerController. Je vais commencer par une rapide comparaison de toutes les méthodes où le passage sous Raven n'apporte rien de nouveau puis je mettrai l'accent sur une différence de conception plutôt intéressante entre les deux implémentations.

Code d'origine

Portage sous Raven

Le code pour Raven est beaucoup plus court pour la bonne et simple raison que j'ai fait disparaitre tout la pseudo gestion d'erreur qu'il contenait.

Code d'origine

Portage sous Raven

Là encore, le fait de faire disparaitre une gestion d'erreur qui n'est là que pour la gallerie a un impact plus que certain sur la taille du code.

Code d'origine

Portage sous Raven

Ici nous avons une différence plus intéressante. Le code d'origine a pour effet d'effacer les commandes qui contiennent l'album supprimé. Ce que ne fait pas le code porté sous Raven.

La notion d'intégrité référentielle n'existe pas sous Raven (ou de façon plus générale sous les bases de données document). Cela peut être un avantage ou un inconvénient. Mais dans ce cas précis, cela s'avère être un avantage puisque nous pouvons supprimer un album sans perdre de commandes. Je ne sais pas pour vous, mais en ce qui me concerne ça ne me déplait pas de conserver toutes mes commandes :)

Avec Raven, les documents sont indépendants les uns des autres. Par conséquent, le fait de modifier un document n'a aucun impact sur les autres documents.

Il reste encore deux méthodes à étudier en ce qui concerne le contrôleur StoreManagerController, mais je verrai ça dans mon prochain billet.

MVC Music Store / Raven DB : Gérer le règlement

Michel — Sun, 30 May 2010 17:41:00 +0200

Ceci est la traduction du billet "Porting MVC Music Store to Raven: Porting the checkout process", le onzième de la série consacrée au portage de l'application MVC Music Store sous RavenDB par Oren Eini, alias Ayende Rahien.

Dans MVC Music Store, la gestion du règlement est composée de deux parties : renseigner l'adresse et le mode de paiement puis terminer la commande.

Le code pour gérer l'adresse et le mode de paiement dans la version d'origine :

Et ce même code correspondant à la version portée sous Raven :

Comme vous pouvez le constater, ils sont presque identiques. Mais le code pour Raven n'est pas tout à fait complet.

Si vous vous souvenez, nous avions décidé de stocker une propriété CountSold dans le document Album, pour pouvoir plus facilement faire un classement en fonction de ce compteur. Il nous reste donc à réaliser l'incrémentation de ce compteur, ce que j'ai codé immédiatement après l'appel à CreateOrder :

Le truc essentiel dans ce code, c'est que nous avons chargé tous les documents albums en une seule requête. Et lorsque nous sauvegardons, Raven va effectuer un seul appel (batch) au serveur.

Et maintenant, pour être tout à fait complet, voyons ce que donnait la méthode Complete() :

Et dans la nouvelle version sous Raven :

Je pense qu'arrivé à ce point, vous êtes en mesure de comprendre comment fonctionne les deux versions.

Mon prochain billet concernera la partie administration de l'application.

MVC Music Store / Raven DB : ShoppingCartController

Michel — Fri, 28 May 2010 13:15:00 +0200

Ceci est la traduction du billet "Porting MVC Music Store to Raven: ShoppingCart", le dixième de la série consacrée au portage de l'application MVC Music Store sous RavenDB par Oren Eini, alias Ayende Rahien.

Le contrôleur ShoppingCartController est considérablement impacté par tous les changements que nous avons apportés à la classe ShoppingCart. Penchons-nous sur ces modifications, en commençant par l'action Index() dans le code d'origine :

Celui-ci exécute deux requêtes différentes pour gérer la commande alors que la version pour Raven exécute seulement une requête au niveau de la méthode FindShoppingCart () :

Ce code implémente seulement la logique pour charger le panier depuis Raven ou créer un nouveau panier (pour l'identifiant spécifié). Notez-bien que nous n'enregistrons pas le nouveau panier dans la base de données, mais associons seulement ce nouveau panier avec la session. Nous n'avons pas besoin de sauvegarder étant donné que pour l'instant il ne contient rien de significatif. Lorsque nous appellerons SaveChanges(), le nouveau panier sera envoyé vers Raven pour stockage.

Maintenant, voyons-voir l'action AddToChart d'origine :

Et la version portée sous Raven :

Elles sont très similaires, si ce n'est que dans le cas de Raven, la méthode AddToCart() de la classe ShoppingCart est uniquement concerné par l'ajout d'un nouvel article au panier ou par la mise à jour de la quantité d'un article existant. Ainsi, il n'y a absolument aucun accès à la base de données dans la version pour Raven de la méthode ShoppingCart.AddToCart().

La différence c'est donc que dans l'approche pour Raven, nous appelons la méthode session.SaveChanges() au niveau de l'action. Pour la bonne et simple raison que c'est le bon endroit où faire cela étant donné que le code appelant est en charge de l'environnent, y compris la sauvegarde lorsque cela est nécessaire.

Je pense que le code pour Raven est plutôt facile à suivre. Il y a juste un truc un peu étrange à faire remarquer au niveau de la dernière ligne : id.Split(). Pourquoi diable fait-on ça ?

Et bien c'est parce que Raven utilise des identifiants de la forme "albums/616" et que la valeur DeleteId sera utilisé par le code Javascript appelant pour retrouver un élément à partir de son identifiant. Et comme l'identifiant d'un élément HTML ne peut pas contenir de "/", nous ne renvoyons que la partie numérique de l'identifiant. Ce n'est pas un problème puisque dans ce cas précis nous ne gérons que des albums.

Encore une fois, on ne peut pas faire plus simple. Par conséquent, je ferai seulement remarquer qu'avec l'approche suivie par Raven on peut profiter du cache de l'unit of work alors qu'avec le code d'origine non.

Dans mon prochain billet, je m'occuperai de la gestion de la commande.