Contourner l'erreur .net core 3 "Synchronous operations are disallowed..."

Avez ASP .net core 3 vous êtes peut être déjà tombé sur l'erreur suivante :

Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.

Celle-ci se produit quand vous souhaitez interagir de avec la Request ou la Response, sans utiliser de méthodes asynchrones. L'exception levée est parfaitement légitime et reflète une volonté forte de l'équipe ASP .net core de réduire les problèmes de performance et de libération des ressources (je reviendrai dessus dans un prochain article).

Il n'est pas conseillé de passer outre ce changement. Cependant, vous pouvez souhaitez utiliser .net core 3 et ses nouveauté à court terme sans changer trop en profondeur le code de vos sites. Vous pouvez donc temporairement contourner la configuration à défaut.

Méfiez-vous du "temporaire qui dure".

Pour contourner le problème. Dans un premier temps, il faut modifier le comportement de Kestrel via la méthode ConfigureKestrel du builder. Cela se passe dans le fichier Program.cs de votre application.

public class Program
{
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .ConfigureKestrel(options =>
        {
            options.AllowSynchronousIO = true;
        });
}

Si vous utilisez l'intégration à IIS, il faudra utiliser la méthode Configure<IISServerOptions> de IServiceCollection.

public class Startup
{
    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)
    {
        services.Configure<IISServerOptions>(options =>
        {
            options.AllowSynchronousIO = true;
        });
    }
}

Cela se passe dans le fichier Program.cs de votre application.

Quand votre code n'utilisera plus que du code asynchrone pour manipuler la Request ou la Response, vous pourrez supprimer ces options.

Jérémy Jeanson

Erreurs avec le "deselectAll" de bootstrap-select

Bootstrap-select est un complément bien sympathique à Bootstrap (pour ceux qui ne connaissent pas, il se trouve ici). Malheureusement, sa dernière version a inclue un changement qui peut poser problème (version 1.13.10).

Si vous utilisez la méthode selectpicker avec l’argument "deselectAll", et que l’utilisateur n’a rien sélectionné dans votre liste, vous déclencherez une exception.

Pour éviter le problème, il faut :

  • Utiliser selectpicker("refresh") quand votre liste est vide.
  • Utiliser selectpicker("deselectAll") quand votre liste n’est pas vide.

Exemple avec désactivation du control :

var ctrl = $("#controlId");
ctrl.prop("disabled", true);
if (ctrl.val().length === 0) {
    ctrl.selectpicker("refresh");
}
else {
    ctrl.selectpicker("deselectAll");
}
Jérémy Jeanson

Créer des liens Bootstrap utilisables avec et sans JavaScript

La documentation de Bootstrap fait souvent état de l’usage d’ancres utilisant un # dans son href.


<a href="#" onclick="Foo()">...</a>

Niveau accessibilité, si on vous demande d’avoir un site qui fonctionne sans JavaScript, le lien sera inutilisable (oui, on peut encore vous demander cela en 2019).

Je n’entends pas refaire une explication ici des différents concepts de sémantique HTML, rôle ARIA … etc …. L’objectif est uniquement de rappeler que l’on peut avoir un lien fonctionnel avec et sans JavaScript.

Pour que le lien soit utilisable, il faut prévoir deux comportements :

  • Le premier avec JavaScript : ouvrira certainement une boite de dialogue.
  • Le second sans JavaScript : déclenchera la navigation vers une page.

Pour un site .net MVC, cela est plutôt facile. Il suffit de prévoir deux vues :

  • Une vue partielle pour l’encapsulation dans la boite de dialogue
  • Une vue qui embarque la vue partielle pour permettre la navigation de l’utilisateur sans JavaScript.

Côté HTTML de l’ancre, cela n’est pas compliqué.


<a href="/Controller/Action" onclick="Foo(); return false">...</a>

Comme cela, c’est un peu plus clair et cela fonctionne avec et sans JavaScript :

  • Le lien sert de bouton.
  • Avec JavaScript, au clavier, il fonctionnera comme un bouton.
  • Avec JavaScript, il fonctionne au click.
  • Sans JavaScript, on lance une navigation.

Old school, mais utilisable.

Pour une écriture plus propre, la fonction Foo() peut directement retourner false.

Jérémy Jeanson

Non, la dématérialisation n’est pas LA solution pour l’accessibilité aux démarches administratives !

Avant d’en dire plus long, sachez que je suis un fervent défenseur de la dématérialisation. Je trouve louable, toute initiative qui conduit à rendre une démarche possible à toute heure de la journée et sans avoir à utiliser papiers et enveloppes. Si en plus cela concerne des services publics, je suis très enthousiaste.

Malheureusement, je suis aussi défenseur de l’accessibilité. C’est ce qui me conduit à écrire cet article.

Non, l’accessibilité ne concerne pas que les aveugles et le web !

Trop souvent, quand une société entame un processus pour rendre accessible un service, elle part avec deux préjugés :

  • L’accessibilité ne concernerait que les aveugles.
  • L’accessibilité n’existe que pour le web.

Aucune de ces idées n’est vraie. Pour résumer simplement :

  • L’accessibilité est pour tous.
  • L’accessibilité se pratique sur tout support numérique.

Quand on dit « tous », de qui parle-t-on ?

Bien évidemment, quand on parle d’accessibilité, on pense handicap. Mais quand on pense handicape, on fait une nouvelle erreur. On ne s’attache qu’aux handicaps visibles :

  • Aveugles.
  • Personnes en fauteuil roulant.

La liste est un peu trop courte. Si l’on prend le temps de regarder du côté d’une norme comme le RGAA, on se concentrera sur les difficultés :

  • Sensorielles.
  • Mentales.
  • Motrices.

Concrètement, on ajoutera toutes les personnes qui :

  • On des problèmes de vue partielle (vue périphérique ou centrale limitée, cataracte, glaucome, rétinopathie ... etc.).
  • On des difficultés à discerner les formes (problème de vue, ou trouble Dys).
  • On des difficultés à percevoir les couleurs (voir incapacité totale).
  • On des difficultés à manipuler une souris et/ou un clavier (voir incapacité totale).
  • On un handicap mental, ou un trouble passager qui perturbe leur résonnement et la capacité à s’adapter (choc à la suite d’un accident, fatigue, stress).
  • On un trouble de la mémoire ou de l’attention (Alzheimer, autisme, mémoire peu développée).
  • … etc.

S’ajoutent à cela les cas que l’on oublie toujours (volontairement ou non) :

  • Sourds ou mal entendant (je ne sais pas pourquoi on les oublie si souvent).
  • Les personnes qui n’ont jamais utilisé un ordinateur, une tablette ou un mobile (ou qui changent de systèmes d’exploitation).
  • Les personnes âgées (que l’on oublie de moins en moins).

Toute personne qui peut avoir des difficultés à utiliser votre application ou votre site est concernée.

L’accessibilité est donc un sujet qui concernera tout le monde un jour ou l’autre, ponctuellement ou continuellement.

Quand on dit tout support, lesquels ?

Pourquoi se limiter à rendre un site accessible ? Quand une personne accède à un site accessible, il faut bien évidemment qu’elle dispose d’un navigateur. Celui-ci doit donc être accessible. Pour pouvoir lancer le navigateur, il faut un système d’exploitation. Celui-ci doit aussi être accessible. Aujourd’hui, on trouve un navigateur sur les ordinateurs, les tablettes et les mobiles. Il faut donc que ceux-ci soient accessibles. L’accessibilité commence donc dès l’appui sur le bouton « On » de votre matériel.

Il n’y a donc pas de raison de se limiter. Rendre un site accessible n’est donc qu’une partie du travail.

Quand vous développez et distribuez une application, il serait donc bon qu’elle soit aussi accessible. Sans quoi, vous allez perdre une partie de vos utilisateurs potentiels (et donc, des parts de marché).

Si vous travaillez à destination des marchés publics (services publics, état français, collectivités …etc.), c’est une obligation. Dans ce cadre, c’est vous qui êtes responsable et non l’organisme prescripteur, ou l’acquéreur (contrairement à ce que laisse croire la légende urbaine). Si vous être pris à défaut et mis en demeure, vous risquez de ne plus être en mesure de distribuer vos produits dans le cadre de marchés publics. Il y a aussi la possibilité de se voir contraint de dédommager les personnes lésées pour le préjudice causé (je ne sais pas si cela a déjà eu lieu).

Moralité

L’accessibilité, c’est bien partout et pour tous.

Jérémy Jeanson