blog.pagesd.info

Dans les mois à venir, je vais avoir à participer à la re-écriture en ASP.NET MVC d'une application existante développée depuis des années en ASP.NET 1.1.

Après de longues tergiversations, il a bien fallu reconnaitre qu'une simple migration en ASP.NET 3.5 et de simples rustines n'étaient ni suffisantes ni envisageables (même pas en rêve mon ami !).

Le problème avec cette application, c'est qu'elle est le résultat d'un empilement continuel de nouvelles fonctionnalités (une fuite en avant perpétuelle ?) et qu'à aucun moment il a été accepté de prendre des pauses pour réaliser les consolidations nécessaires si on voulait que l'ensemble puisse évoluer (voire fonctionner) sereinement.

Ce qui fait qu'aujourd'hui, on a la chance d'avoir une grosse ... avec dans le tas des trucs certainement utiles mais aussi des trucs complètements stupides, des trucs réalisées pour faire plaisir à des gens qui n'ont jamais mis les pieds dans l'application, des trucs développés et toujours pas passés en production 1 an près, des trucs pour que "ça se fait tout seul y a rien à faire", des trucs pour contourner d'autres trucs qui ne marchent pas comme on veut qui faudrait que ça marche, des trucs qu'on est pas sûr que ça serve mais yaka les laisser, des trucs qui prennent une éternité pour faire 3 fois rien, des trucs qui ont été demandés parce qu'on sait jamais ça pourrait toujours servir un jour ou l'autre...

Pour résumer ma pensée, il est plus qu'indispensable de commencer par un énorme travail de réflexion sur le contenu de ce ramassis avant même de penser à démarrer un Visual Studio. Et par réfléchir j'entends supprimer ce qui ne sert pas, supprimer ce qui ne marche pas, supprimer ce qui n’est pas indispensable, supprimer ce qui n’est pas faisable, supprimer ce qui prendra trop de temps à faire, etc… En bref éviter de re-développer des fonctionnalités en pagaille et prendre le risque de re-venir à notre point de départ...

Mon souci c'est que le spectre d'une migration iso-fonctionnelle flotte encore dans l'air : on part de tout ça et au final on veut toujours tout ça (et un peu plus) mais en mieux. Et comme on est très conciliants, on pourrait à la rigueur accepter de sacrifier quelques écrans à condition qu'on retrouve leurs fonctionnalités dans d'autres écrans...

Voilà donc un de mes stress du moment. Mais ce matin, qu'est-ce que je découvre dans mon Bloglines ? Un article des créateurs de Scout qui explique qu'en supprimant des tonnes de code (y compris des fonctionnalités), ils ont amélioré leur application tant d'un point de vue performance (jusqu'à x 10 sur les traitements les plus couteux) que satisfaction de leurs clients. Et en plus ils nous nous livrent les deux leçons que l'on peut en retirer :

1. Arrêter de vouloir faire simple pour l'utilisateur final au prix d'une tarabiscotisation dans le code, mais chercher la simplicité dans la façon de faire (et perso, je pense que si c'est simple à faire, c'est évident à utiliser).

It turns out that simplicity and elegance for the end user can mean some awfully complicated stuff behind the scenes to make it work.

2. Arrêter de perdre son temps sur l'ajout de nouvelles fonctionnalités soi-disant incontournables qui vont cannibaliser notre temps et notre énergie juste pour les mettre au point

If you’re running a web application and the majority of your work is spent delivering the service you advertised to your customers, you’re probably in bad shape.

Ca, ça me plait !

Ce billet est avant tout une sorte de message de service qui est essentiellement destiné à tenir deux collègues au courant de tout ce qui s'est passé sur PI et AP ces derniers temps.

Les modifications de PI (Pages d'Infos)

Les cinémas

J'ai fait pas mal de mises à jour sur les programmes de cinéma et il y a maintenant 3 présentations pour les séances :

• affiches avec un tableau des séances hebdomadaires (jour par jour)
• affiches avec un tableau des séances quotidiennes (heure par heure)
• seulement les affiches

Et quand c'est disponible, la description et le réalisateur du film sont aussi affichés.

Pour l'Ardèche, j'utilise le tableau hebdo avec les cinémas où il y a peu de films et le tableau jour pour les autres.

Jusqu'à présent, les anciennes séances de dir_Seances étaient conservées seulement pendant 2 semaines (14 jours). J'ai passé ça à 5 semaines (35 jours) pour éviter de perdre trop vite les descriptions et les informations liées au film dans la table dir_Movies (et donc d'avoir à les re-saisir quand le film passe enfin dans les petites salles de l'Ardèche). En effet, on supprime les films de dir_Movies dès qu'ils n'apparaissent plus dans dir_Seances.

Et enfin, j'ai ajouté un champ "information" à la table dir_Cinemas pour ajouter une information ponctuelle à la page d'un cinéma. Si ce champ commence par un "!", il ne s'affiche que dans le cas où il n'y a pas de séances connues : je m'en suis servi pour afficher les périodes de fermeture des cinémas pendant l'été.

Les communes

Le template _PlaceTemplate.txt employé pour les communes gère maintenant une macro {@place.urlOffice} pour afficher un lien vers l'office de tourisme. Pour l'Ardèche, c'est un lien vers la page interne consacrée à l'office de tourisme.

Pour cela, le champ urlOffice de la table dir_Places contient :

<a href="[%AP.Path.Application%]annuaire/office-tourisme/mon-village.aspx" title="Office-tourisme">OT de Mon Village**</a>

(admirez l'utilisation des macros Altrr-Press :)

Pour vous, vous pouvez mettre directement quelque chose comme :

<a href="http://www.ot-mon-village.fr/"> title="Office tourisme">OT de Mon Village **</a>

J'ai aussi ajouté la macro {@place.weather} pour insérer l'encart météo juste au moment du rendu de la page d'une commune.

Avec la nouvelle macro {@place.htmlDescription} (ou {@place.description}), ce qui m'a permis de créer un encart avec :

• un lien vers office de tourisme
• la météo de la commune
• une mini-description de la commune

La macro {@place.description} renvoie juste le contenu du champ description de la table dir_Places. Par contre, la macro {@place.htmlDescription} génère du code html autour pour intégrer la description :

• <p class="infodesc">la description de la commune ...</p>
• <blockquote><p>une citation sur la commune ...<cite>l'auteur de la citation</cite></p></blockquote>

La macro {@place.htmlDescription} détermine automatiquement que le champ description contient une citation lorsqu'il y a un séparateur pipe | entre la citation et l'auteur.

Par ailleurs, la description brute est utilisée pour la balise meta description de la page. C'est ce qui est conseillé par les outils Google pour les webmasters pour avoir moins de pages avec la même description.

Les liens

Je ne fais plus apparaitre de publicité à l'intérieur des liens lorsqu'ils sont affichés sous forme minimisée. Parce que ça faisait trop de publicité dans la page par rapport au contenu texte. Ce qui faisait que dans certains cas, Google laissait vide le bandeau latéral sur la droite.

Il y a maintenant un champ displayMode dans la table dir_Tags pour choisir comment présenter la liste des liens d'un tag :

• Défaut : initialisé à 0 pour les tags qui ont moins de 100 liens
• Par commune : initialisé à 1 pour les tags avec au moins 100 liens

La présentation par commune affiche les tags en les classant par commune, comme on peut par exemple le voir dans la page des restos de l'Ardèche. Les pages concernées sont beaucoup plus légères qu'avant et je trouve que c'est plus pratique à lire et pour y trouver d'un coup d'oeil les sites d'une commune.

En vrac

Il est maintenant possible de modifier un marché (avant il fallait aller taper dans la base de données).

J'ai modifié la présentation des évènements. Maintenant ça fait vraiment trop comme dans les sites internet pour de vrai ! (mais y'a que moi qui en profite).

J'ai optimisé pas mal de code en remplaçant de nombreuses variables string par des StringBuilder.

La très vielle AjaxBox (3 ans et demi quand même) a complètement été évincée au profit du tout nouveau AutoComplete (en attendant jQuery peut être un jour ou l'autre).

Sinon, j'avais commencé à ajouter du code pour gérer la version 2 des Pages d'Infos (avec notamment une nouvelle charte graphique plus moderne), mais ça fait un bon bout de temps que je n'ai rien fait dessus.

Les modifications de AP (Altrr-Press)

Moins de code

Pour résumer, l'objectif général de toutes les modifications apportées à Altrr-Press c'est de diminuer la quantité de code (si besoin en réduisant les fonctionnalités) et d'améliorer la qualité du code restant (ou en tout cas de le simplifier au maximum). Tout ça en vue d'arriver à faire une version 1 avant de passer très vide à une version 2 qui tournerait sous ASP.NET 2.

J'ai définitivement supprimé les boites FlashFile, Image, Redirect, Sitemap et Sitemenu qui ne sont normalement plus utilisées depuis pas mal de temps (ou alors vous êtes vraiment à la traine).

J'ai aussi supprimé la boite SqlRepeat qui ne servait que sur le site de Saint-Privat (et la preuve que je suis prêt à tout pour diminuer la quantité de code, c'est que j'ai utilisé du XML pour la remplacer).

Pour plus d'explications, vous pouvez vous reporter au billet Régime XML.

Un nouveau Wysiwyg

J'ai aussi définitivement remplacé l'éditeur wysiwyg widgEditor par Altrr-Editt, un super nouveau éditeur wysiwyg que j'ai fait moi-même en reprenant des morceaux de widgEditor à la sauce jQuery.

Il est plus mieux bien, vous pouvez me faire confiance, même s'il faudra attendre encore un petit peu pour que je trouve le temps de vous expliquer pourquoi.

Mise à jour des macros

Désormais, toutes les macros de AP sont sous la forme [%AP.Xxxxxx.Yyyyyy%]. Pour rappel, les macros c'est les trucs qu'on peut utiliser dans les chartes graphiques ou les boites RawContent. Avant, on avait vraiment de tout et n'importe quoi :

• {@department.xxxx} pour les informations sur le département
• <%= siteMacro("xxxxx") %> dans les chartes graphiques
• et même {@public.start} et {@public.end} pour encadrer les scripts de statistiques

Pour l'instant, le source de default.aspx.cs contient encore les fonctions siteMacro() et RenderLegacy() pour gérer toutes les anciennes syntaxes, mais je compte bien m'en débarrasser le plus vide possible.

A noter : à part {@department.xxxx} qui est devenu [%AP.Department.Xxxxx%], toutes les autres macros de PI utilisées dans les templates /data/##/_xxxxx.txt sont restées sous la forme {@objet.propriete}.

Et accessoirement, les macros ne sont plus statiques (je me demande bien comment il pouvait y avoir du statique là dedans ?). A mon avis, il y a une petite chance que ça permette de résoudre les plantages pour le Gîte de Julie.

J'ai aussi ajouté les macros [%AP.Link.Next%] et [%AP.Link.Previous%] pour générer un lien vers la page suivante ou la page précédente à l'intérieur d'un même niveau d'arborescence. Vous pouvez aller voir les 2 galeries de photos sur le site de Saint-Privat pour voir ce que ça donne. Au passage, ces 2 galeries contiennent du XML, saurez-vous le retrouver ?

Poliçage du code

J'ai aussi essayé de passer les sources d'Altrr-Press à la moulinette StyleCop (c'est un programme made in Microsoft pour valider l'organisation et le style des sources C#), mais c'est pas simple parce qu'il faut faire les corrections à la main et qu'en plus ils prônent un style qui n'est pas très "AP like" (surtout pour les { et les } sur des lignes séparées !!!).

Malgré tout, il y a quelques trucs intéressants :

• utiliser string.Empty au lieu de ""
• mettre les using à l'intérieur du namespace (et pas une fois l'un et une fois l'autre)
• commenter beaucoup plus (tout commenter en fait)
• espacer pour que ça soit plus clair (ajouter des lignes vides)
• utiliser this.xxxx
• return xxxx; et pas return (xxxx);
• etc...

Sur BDHlper.cs où j'ai fait le plus de travail il y a encore 392 avertissements (heureusement y'en a beaucoup qui sont liés les uns aux autres).

Pour la suite

J'ai le début d'un autre billet en préparation sur tout ce qu'il est nécessaire de prévoir pour faire passer Altrr-Press en ASP.NET 2. Et j'ai peur que ça implique pas mal de trucs...

Et il faudrait aussi graver dans le blog comment je compte faire évoluer Altrr-Press :

• verrouiller le périmètre de ce qui sera dans la version 1 (idéalement ne plus rien ajouter)
• version 2 (périmètre identique sous ASP.NET 2) : comment s'y prendre et comment tester
• les priorités / les indispensables à incorporer dans une version 2.1
• les idées pour plus loin...

Mais en attendant, il faut aussi que je m'occupe de finaliser les scripts SQL qui permettront aux retardataires de faire une mise à jour quasi sans douleur par rapport à toutes les modifications répertoriées dans ce billet.

Cet été, j'ai eu envie d'un Altrr-Press tout beau, tout propre pour qu'il soit encore plus simple à utiliser et aussi un peu plus prêt pour le grand jour du passage sous .Net 2.0 (ou plus) : moins de code = moins de problèmes lors de la conversion.

Pour commencer, je me suis enfin décidé à supprimer les sources d'un certain nombre de boites devenues inutiles mais dont les codes sources avaient été épargnés (voire un peu oubliés) en attendant que tous les sites existant soient mis à jour.

• FlashFile : insérait une animation flash (remplacé par IncludeFile)
• Image : insérait une image (remplacé par IncludeFile)
• Redirect : redirige le client vers une autre URL (remplacé par la macro [%AP.Redirect:url%])
• Sitemap : insérait le plan du site (remplacé par la macro [%AP.Site.Map%])
• Sitemenu : menu ou sous-menu de navigation (remplacé par la macro [%AP.Site.Menu:level1-level2%])

Note : si vous connaissez des sites qui ont encore besoin de ces boites, 20071029_update.sql et 20071030_update.sql sont vos amis.

Pour continuer sur ma lancée, j'ai aussi cherché comment éliminer la boite SqlRepeat qui prend le résultat d'une requête sous forme de DataReader pour générer un tableau HTML à l'aide d'un système de template très primaire.

D'abord, il y a le template d'en-tête :

<table class='repertoire'>

Puis le template pour le détail des lignes :

<tr>
  <td class='col1'>{0}<br /></td>
  <td class='col2'>{1} {3} {2}<br />{4}</td>
  <td class='col3'>Tél:&amp;nbsp; {7}<br />Fax: {8}</td>
</tr>

Et pour finir celui pour la fin du tableau :

</table>

Et côté code, en simplifiant ça donne à peu près ça :

StringBuilder html = new StringBuilder();
html.Append(templateHead);
DataReader dr = Data.Base.ExecuteReader(sqlQuery);
while (dr.Read()) {
  html.Append(ToHtmlRow(dr, templateLoop));
}
dr.Close();
html.Append(templateFoot);

Pour chaque ligne du DataReader, la fonction ToHtmlRow() génère une ligne en remplaçant les marqueurs {#} par la colonne correspondante dans la ligne en cours DataReader.

Le but étant de supprimer une boite, il faut donc trouver par quoi la remplacer. Le plus simple est de passer par la boite à tout faire RawContent et d'y coller le tableau HTML final. Etant donné que cette boite n'est utilisée que sur le site de Saint-Privat, cela semble une solution raisonnable. Malgré tout, la boite RawContent est plutôt destinée aux petits bouts de codes de quelques lignes et là les tableaux HTML dépassent la toise.

Alors j'ai cherché s'il n'y aurait pas une autre méthode. Et TILT : XML. Ah ben ZUT alors!

Normalement, je préfère éviter d'utiliser le XML (et surtout le XSLT) parce que si c'est toujours assez facile quand on commence, on se retrouve vite avec des sacs de noeuds pour faire trois fois rien. (Ou alors il faut recourir à un collègue qui parle le XML couramment mais que quand il a fini j'ai pas toujours compris.) Mais là, l'envie de me débarrasser d'une boite quasiment inutilisée étant la plus forte, j'ai succombé. Et en fait, ça n'a pas été aussi compliqué que ce que je craignais.

Un premier bon point, c'est qu'il existe déjà une boite XmlFile qui prend un fichier XML pour générer du HTML en lui appliquant un fichier XSLT. C'est un truc qui existe depuis toujours dans IBuySpy et que j'ai adapté dans Altrr-Press. Dans la pratique, je ne m'en sers presque jamais, sauf de temps en temps pour afficher des fils RSS ou Atom ou bien des liens enregistrés dans Blogmarks.

Dans le cas présent, il fallait donc que je me débrouille pour prendre le résultat de ma requête comme source XML et surtout que je réussisse à créer un fichier XSLT qui transforme ce résultat en tableau HTML.

Pour la source XML, c'était vraiment trop facile : quelques minutes à passer dans l'aide et 2 lignes de codes ont suffit (merci le .Net) :

DataSet ds = Data.Base.ExecuteDataSet(sqlQuery);
string xml = ds.GetXml();

Ce qui donne :

<NewDataSet>
  <Table>
    <categories>Electricien</categories>
    <organization>Ets Martin</organization>
    <legalName />
    <givenName />
    <streetAddress>Le Pré-Vert</streetAddress>
    <postalCode>12345</postalCode>
    <placeName>Enville</placeName>
    <workPhone>01 02 03 04 05</workPhone>
    <faxPhone />
  </Table>
  ...
</NewDataSet>

Puis en partant de fichiers XSLT existants et après pas mal d'essais et de messages d'erreurs, j'ai réussi à obtenir un fichier XSLT qui reproduisait le résultat de mon futur ex-système de template :

<xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
  <xsl:template match="/">
    <table class='repertoire'>
    <xsl:for-each select='NewDataSet/Table'>
      <tr>
        <td class='col1'>
          <xsl:value-of select='categories'/>
          <br />
        </td>
        <td class='col2'>
          <xsl:value-of select='organization'/>
          <xsl:if test="givenName != ''">
            <xsl:if test="organization != ''">
              <xsl:text> - </xsl:text>
            </xsl:if>
            <xsl:value-of select='givenName'/>
            <xsl:text> </xsl:text>
            <xsl:value-of select='legalName'/>
          </xsl:if>
          <br />
          <xsl:value-of select='streetAddress'/>
        </td>
        <td class='col3'>
          Tél: <xsl:value-of select='workPhone'/>
          <br />
          <xsl:if test="faxPhone != ''">Fax: <xsl:value-of select='faxPhone'/></xsl:if>
        </td>
      </tr>
    </xsl:for-each>
    </table>
  </xsl:template>
</xsl:stylesheet>

Et même que grâce à l'instruction <code><xsl:if test="faxPhone != ''"> ... </xsl:if></code>, le résultat obtenu est encore mieux que l'original. Si je ne me retenais pas, je passerais tout en XML.

Mais pour l'instant, je vais me contenter de supprimer la boite SqlRepeat et ses 3 fichiers sources devenus inutiles. C'est toujours ça de pris (et au final ça fait quand même 6 boites de moins !).