Bookmarks dans Visual Studio

icon Tags de l'article : , ,

Aout 17, 2018
Woaw, je viens de découvrir l'existence des bookmarks dans Visual Studio...

Comme vous le savez peut-être, je suis un adepte des raccourcis clavier et de l'efficacité... mais je ne m'étais jamais posé la question de l'existence de bookmarks dans Visual Studio.

Pourtant c'est un besoin fréquent, noter un emplacement pour y revenir... A l'origine je me débrouillais en pinnant un fichier ou avec des breakpoints désactivés... Sauf qu'il y a une feature pensée pour !

Son fonctionnement est méga simple :

CTRL + K + K : Mettre/enlever un bookmark
CTRL + K + N : Aller au bookmark suivant
CTRL + K + N : Aller au bookmark précédent
CTRL + K + W : Afficher la liste des bookmarks

La liste ressemble à ça, et elle permet même de nommer ses bookmarks pour s'y retrouver plus facilement !.



En bref, une feature incontournable !

Architecture d'application web : SPA ou classique (en pages)

icon Tags de l'article : , , ,

Aout 16, 2018
Hello les gens,

Aujourd'hui je vais répondre à une question que beaucoup de développeurs se posent quand ils vont commencer un nouveau projet web : dois-je tenter l'aventure SPA (Single Page Application) ou dois-je rester sur une architecture classique (en pages web).

Pour répondre à ça, j'ai décidé de faire un petit listing des points positifs et négatifs d'une application SPA par rapport à une application classique.
A noter que c'est ma vision perso, après 6 ans à travailler sur des sites en pages web et 4 ans sur une application SPA.

Positif
  • Un code plus propre, mieux organisé, qui force à la rigueur
  • Un code JS beaucoup plus clair et parfaitement intégré aux vues
  • Moins de requêtes (stockage JS, moins de données à envoyer en permanence au serveur)
  • Possibilité d'avoir énormément de choses côté client (gros traitements, calculs, process en X étapes, etc.)
  • Maintenance et évolution plus facile
  • Pour l'utilisateur : une navigation plus agréable dans l'application

Négatif
  • Quel framework choisir ? Angular ? Vue.js ? React ? Un autre ?
  • Demande plus de rigueur en permanence (découpage en fichiers, architecture, dépendances JS, etc.)
  • Un temps de dev plus long (temps d'adaptation au langage, plus de javascript, temps pour trouver quel morceau de code correspond à quoi, plus de classes à écrire, ...)
  • Un debug plus compliqué au quotidien
  • Référencement et Routing
  • Monitoring des performances et tests d'intrusion moins évidents
  • Problématiques de mise à jour (si la personne ne refresh jamais, comment forcer la mise à jour sans lui faire perdre des données en cours de saisie ?)
  • Pour l'utilisateur : un premier chargement plus long

Pour moi, si j'avais à choisir entre une architecture SPA vs design classique, je poserais deux questions :
  • L'utilisateur de l'application fera-t-il de grosses sessions dessus ? (20 minutes ou plus)
  • Ais-je le temps et les moyens d'investir dans une SPA ? (car rien que la structure SPA rajoutera des problématiques à gérer au jour le jour)

Si vous avez un OUI aux deux questions, vous pouvez partir sur une architecture de type SPA sans hésiter. Le confort d'utilisation apporté à l'utilisateur par une SPA vaut vraiment le détour pour une application sur laquelle l'utilisateur passera des heures.

Après, personnellement, j'ai tendance à préférer une approche entre les deux :
  • Un site classique, découpé en pages
  • Chaque page utilisant un modèle de vue JS et un moteur de binding (dans mon cas Knockout)

Pourquoi ?
Après 4 ans passés à travailler sur une SPA, je me suis rendu compte que revenir à un design en pages web ne me posait pas de soucis. Au contraire, le développement devient plus simple.
La vraie problématique que je retrouve... c'est le JavaScript "à l'ancienne". Avoir un peu partout des méthodes qui font des modifications dans l'interface rend le tout extrêmement compliqué à relire et à améliorer.
Garder un design en pages web auquel on ajouterait un moteur de binding JS me parait être le meilleur compromis d'entre les deux mondes.

Après, évidemment... tout dépend de la taille de votre projet, de vos moyens... et de vos goûts ;)

Bonne journée et bon dev à tous/toutes !

Créer un template Razor utilisable en JavaScript

icon Tags de l'article : , , ,

Aout 15, 2018
Hello tout le monde,

Aujourd'hui on va voir comment créer un template Razor utilisable en JavaScript.
C'est une problématique assez courante, et la solution que je propose vient d'une implémentation sur un projet pro... et le résultat est pas si mal.

A noter qu'on est à des années lumières d'un vrai moteur de template, et je ne peux que vous recommander d'en implémenter un si c'est un vrai besoin de votre projet.
Cette solution n'est proposée que pour dépanner, ou à utiliser sur un projet où on ne peut/veut implémenter de moteur de template.


Du coup, allons-y !

Tout d'abord, on va créer une vue partielle pour notre template :

@model Projet.ObjetHtmlTemplate

<div class="objet">
    <h1>@Model.Name</h1>
    <p>@Model.Description</p>
    <span class="price">@Model.Price</span>
</div>

Nous allons maintenant créer notre ViewModel, ici ObjetHtmlTemplate.

Deux choses sont cependant à noter sur ce template :
  • Tous ces champs sont des strings
  • Le constructeur va permettre une initialisation des champs avec une chaine en dur contenant des antiquotes et le nom de la variable.

Voyons la classe avant que j'explique le "pourquoi" :

public class ObjetHtmlTemplate
{
    public string Name { get; set; }
	
	public string Description { get; set; }
	
	public string Price { get; set; }
	
	public ObjetHtmlTemplate(bool initForJs = false)
	{
		if(initForJs) 
		{
			Name = "` + Name + `";
			Description = "` + Description + `";
			Price = "` + Price + `";
		}
	}
}

Voilà. Je pense que vous commencez à voir où je veux en venir : nous allons juste créer une méthode en JS qui prendra en paramètres Name, Description et Price, et cela renverra... le HTML généré préalablement par Razor... mais avec nos valeurs JS !

La prochaine étape est donc ce petit morceau de JavaScript dans notre vue :

<script>
	var getObjetHtml = function(Name, Description, Price) {
		return `@Model.Partial("_ObjetHtmlTemplate", new ObjetHtmlTemplate(true))`;
	};
</script>

Magique non ? Maintenant on a une jolie méthode JavaScript "getObjetHtml" qui prend 3 paramètres, et qui va renvoyer le HTML généré à partir de ces 3 paramètres. <3

Et côté ASP.Net, on peut utiliser notre vue partielle comme à notre habitude :

<ul>
@foreach(var item in Model.Items)
{
	<li>@Html.RenderPartial("_ObjetHtmlTemplate", new ObjetHtmlTemplate() { Name = item.Name, Description = item.Description, Price = Math.Round(item.Price, 2) })<li>
}
</ul>

Et... c'est tout ! Simple et efficace, que demander de plus ?!

Allez, bonne journée et bon dev à tous/toutes !

Manipuler une collection de sous-objets dans une vue ASP.Net MVC

icon Tags de l'article : , , ,

Aout 13, 2018
Hello les devs !

Aujourd'hui on va parler d'une problématique assez commune : envoyer des sous-objets au serveur depuis une vue CSHTML.

En effet, quand on développe un site avec ASP.Net MVC, il peut arriver qu'on ait besoin, dans notre vue, de manipuler des objets qui sont en fait... une collection d'objets liés à notre objet principal.

Exemple : ma classe Guerrier qui a une propriété "Inventaire" contenant une collection d'"Objet".

Dans ma vue, j'aimerais donc pouvoir voir les objets dans l'inventaire, et si besoin... en ajouter/supprimer.

Comment faire ça ?

Et bien en fait c'est ultra simple : le moteur d'ASP.Net MVC sait tout à fait mapper des sous-objets à partir de nommages façon "tableau".

Exemple : <input type="text" name="Guerrier.Inventaire[0].Nom" value="Epée des mille vérités" />

Grâce à la syntaxe "Inventaire[0].Nom", le moteur d'ASP.Net va comprendre de lui-même qu'il s'agit du premier objet dans la liste "Inventaire" et va essayer de le créer et mapper ses propriétés.

Quelques choses à noter tout de même :
  • Attention à la numérotation, si vous avez juste un sous-objet numéroté [1], il ne sera pas mappé et récupéré.
  • Côté serveur vous ne récupérerez que ce qui a été envoyé par le client. S'il s'agit de données à sauvegarder, vous devrez faire une comparaison entre ce que vous avez en base et ce que l'utilisateur a envoyé.
  • Si vous n'avez pas de valeurs, vous n'aurez pas d'objets.
  • Si vous n'avez pas d'objets, vous ne récupérerez pas une collection vide, mais null.
  • Si jamais les champs sont disabled, ils ne seront ni récupérés, ni mappés (pratique pour activer/désactiver un objet en javascript).

Voilà,

Bonne semaine et bon dev à tous/toutes !

Bug avec bootstrap-datepicker dans sa version v4.17.45

icon Tags de l'article : , , ,

Aout 10, 2018
Hello,

Juste un micro article pour vous prévenir d'un bug dans la version 4.17.45 du bootstrap-datepicker...

Si vous êtes comme moi et que vous passez par des packages nugets, méfiez-vous : la dernière version en Nuget est la 4.17.45 qui contient des bugs.

(Dont un très chiant : si vous faites une sélection particulière en fonction du format, par exemple une sélection par mois uniquement, au 2eme clic le mode de sélection aura disparu).

Les bugs sont corrigés sur la dernière version en ligne : la 4.17.47.

N'hésitez pas à mettre à jour manuellement votre code, étant donné que le package Nuget est à la masse :(

Bon dev à tous/toutes.