Aricie
The DNN Expert for your web project
Aricie Blog

Dangers de la Culture: gestion des pages sous DotNetNuke 6

Oct 10 2012

Le problème

Si vous utilisez le module de gestion des pages sous un DotNetNuke en culture allemande, italienne ou française, vous allez sans doute rencontrer des problèmes à l'édition de vos pages. Vous choisissez les nouveaux paramètres avec soin:

Puis vous décidez de sauvegarder vos modifications, et DotNetNuke s'écroule en vous détaillant le problème:

Ce message d'erreur n'apparait que si vous avez décidé de désactiver la fonctionnalité Ajax pour le module de gestion des pages. Dans le cas contraire, une ligne dans la console javascript vous avertira; si vous n'avez pas de console javascript active, ou un moyen de constater l'erreur, la page semble se rafraichir correctement mais la modification n'est pas effectuée. Le problème est discret...

 

Mais qu'est-ce qui se passe?

Si j'ai désactivé la fonctionnalité Ajax, c'est parce que c'est le seul moyen de pouvoir consulter la pile d'appel ou se produit l'erreur dans le code DNN. Ce dernier nous apprend qu'il s'agit de la méthode de mise à jour du module "Tabs"

DotNetNuke.Services.Exceptions.PageLoadException: Input string was not in a correct format. ---> System.FormatException: Input string was not in a correct format.
at System.Number.ParseSingle(String value, NumberStyles options, NumberFormatInfo numfmt)
at DesktopModules.Admin.Tabs.View.CmdUpdateClick(Object sender, EventArgs e)
at System.Web.UI.WebControls.LinkButton.OnClick(EventArgs e)

Un peu d'exploration dans le code du module (qui se trouve dans le répertoire DesktopModules/Admin/Tabs/Tabs.ascx.cs) nous amène rapidement au coupable le plus probable.

 

Pourquoi la priorité de sitemap poserait problème? Le problème vient du code du module de gestion des pages. Ce dernier tente d'analyser la valeur de cette priorité avec ce morceau de code.

tab.SiteMapPriority = float.Parse(txtSitemapPriority.Text);

Ce code analyse la valeur passée dans la boite de text en utilisant la culture courante de la page. Or si nous sommes dans une culture qui n'utilise pas le point comme séparateur décimal (comme par exemple le français) alors l'analyse de la valeur 0.5 va échouer. On peut le vérifier rapidement en testant les modifications dans le module après avoir remplacé le séparateur point par un séparateur virgule.

Et ça marche!

Pourquoi ça arrive?

En un mot: asymétrie. En plusieurs, c'est parce que le module a prévu le cas ou une culture utiliserait un autre séparateur que le point au moment de l'affichage, mais pas au moment de la récupération des données. Voici comment le module affiche la valeur de priorité:

txtSitemapPriority.Text = tab.SiteMapPriority.ToString(CultureInfo.InvariantCulture);

Comme vous le voyez, la culture invariante est spécifiée afin de forcer l'utilisation d'un format unique. Mais comme nous l'avons vu, lors de la récupération la culture invariante n'est pas précisée. D’où l'erreur d'analyse des valeurs. Si la culture invariante n'avait pas été utilisée, la valeur à l'affichage aurait utilisé le même séparateur décimal qu'à la récupération des données.

Comment le corriger?

Après analyse, j'ai découvert que le souci avait déjà été remonté à DotNetNuke. Malheureusement, la correction n'est prévue que pour la version... 7! Pas vraiment d'autre moyen de fonctionner qu'en corrigeant le code directement. L'article mentionne une correction possible qui est de rajouter la culture invariante à l'analyse. Il s'agit donc de changer cette ligne de code dans Tabs.ascx.cs

tab.SiteMapPriority = float.Parse(txtSitemapPriority.Text);

en

tab.SiteMapPriority = float.Parse(txtSitemapPriority.Text, CultureInfo.InvariantCulture);

Une autre possibilité est de modifier l'affichage si le respect du format de culture est important pour vous. Pour cela vous devrez changer la ligne suivante

txtSitemapPriority.Text = tab.SiteMapPriority.ToString(CultureInfo.InvariantCulture);

en

txtSitemapPriority.Text = tab.SiteMapPriority.ToString();

Personnellement, je préfère utiliser le point comme séparateur, car ils est présent dans le pavé numérique de la plupart des claviers, mais sur certaines interfaces l'adhésion à la culture affichée est importante. Vous pourriez même utiliser un javascript qui transforme indifféremment les séparateurs dans la bonne culture sur les champs adéquats, mais l'exercice est laissé au lecteur :)

Bloggers
Jesse's blog
 Jesse
 1  9  12/6/2014
Musings without a muse
 samyb
 6  95  1/3/2013
Stephane DNN Blog
 Stéphane TETARD
 1  3  4/23/2012
Categories