Au menu :
– Refonte du plan de la FAQ
– Mise à jour de questions/réponses obsolètes
– Ajout de 60 nouvelles questions/réponses

Vous pouvez laissez vos avis/commentaires/suggestions sur ce billet ou sur le forum

Au menu :
– Refonte du plan de la FAQ
– Mise à jour de questions/réponses obsolètes
– Ajout de 28 nouvelles questions/réponses

Vous pouvez laissez vos avis/commentaires/suggestions sur ce billet ou sur le forum

Et il a tout à fait raison.

Mais pourquoi ne peut-on pas avoir plusieurs formulaires avec runat=server sur une même page ?

Il serait d’ailleurs plus judicieux de préciser qu’on ne peut pas avoir plusieurs formulaires visible sur la même page.

En effet

   1: <form id="form1" runat="server">

   2: </form>

   3: <form id="form2" runat="server" visible="false">

   4: </form>

ne posera pas de problème d’exécution, tandis que :

   1: <form id="form1" runat="server">

   2: </form>

   3: <form id="form2" runat="server">

   4: </form> 

levera l’HttpException suivante :   

A page can have only one server-side Form tag.

Le modèle de programmation à formulaire unique (Single Form Model) est fait de manière à n’avoir qu’une seule balise form visible, avec l’attribut runat = server. Cela permet à ASP.NET de gérer les contrôles qui sont posés dans le formulaire, ayant la balise runat=server, coté serveur. Cela permet entre autre de pouvoir y accéder dans le code behind directement.

Le modèle de développement impose que les éléments de formulaire soient postés à la même page qui les a soumis, ce qui permet aux mécanismes d’ASP.NET (ViewState, etc …) de fonctionner correctement.

Pour la curiosité, la pile d’appel au moment de l’exception nous permet de constater que l’exception est levée au moment de l’appel à la méthode System.Web.UI.Page.OnFormRender()

Un petit coup de reflector nous permet de voir

   1: internal void OnFormRender()

   2: {

   3:  if (this._fOnFormRenderCalled)

   4:  {

   5:    throw new HttpException(SR.GetString("Multiple_forms_not_allowed"));

   6:  }

   7:  this._fOnFormRenderCalled = true;

   8:  this._inOnFormRender = true;

   9: } 

Cette méthode OnFormRender est appelée au moment du rendu du contrôle HtmlForm. Le code issu de Reflector nous permet bien de constater qu’un boolean est mis à vrai lors du rendu d’un contrôle HtmlForm. Si ce boolean est déjà à vrai, alors l’exception est levée.

Cette entrée de faq sera modifiée à la prochaine (très bientôt) mise à jour.

Il faut dire qu’il s’agit d’un problème qui arrive dans le cas suivant :

On dispose d’une masterpage, ex (un peu épuré) :

Lorsque l’on crée une page qui utilise cette masterpage et qui remplit le ContentPlaceHolder, ex :

Si j’essaie d’accéder à mon label dans le OnPreInit de la page, ex :

J’aurai une exception parce que mon label vaut null. Argh ! Problème !

La raison à ce comportement, c’est que dans le PreInit, la masterpage n’est pas encore initialisée.

Pour que mon label ne soit pas null, il faut que je force l’initialisation de ma MasterPage, et accédant à l’objet Master.

On pourra faire ainsi :

Désormais, leLabel ne sera plus null et nous serons heureux

j’ai fait la mise à jour des faqs ASP.NET

La FAQ ASP.NET C# : 362 questions à vos réponses, dont 12 nouvelles
La FAQ ASP.NET VB.NET : 312 questions à vos réponses, dont 14 nouvelles

N’hésitez pas à aller y faire un tour.

Pour la prochaine mise à jour, je promets de remettre un peu d’ordre dans le sommaire et de remettre à jour quelques questions/réponses un peu vieillottes…

Bonne lecture.

La FAQ ASP.NET C# : 350 questions à vos réponses, dont 16 nouvelles
La FAQ ASP.NET VB.NET : 298 questions à vos réponses, dont 21 nouvelles

Pour reprendre mon exemple précédent, Page2 pourra recevoir comme directive :

<%@ PreviousPageType VirtualPath="~/Default.aspx" %>

ce qui fait que dans le codebehind, on aura plus besoin de cast et on pourra utiliser directement

MonLabel.Text = PreviousPage.GetValue();

En fait, le designer nous surchage simplement la propriété :

Ce qui lèvera une exception si jamais on vient d’une autre page …

Travaillant au quotidien en asp.net C# et étant trilingue dotnet ( ), il est temps de créer une nouvelle catégorie sur mon blog ASP.NET ; ce blog va donc s’enrichir pour parler également d’asp.net puisque je m’occupe désormais des faqs asp.net (C# et VB.net).

Mon premier billet asp.net sera donc l’annonce d’une mise à jour de ces faqs, à savoir :

La FAQ ASP.NET C# : 334 réponses à vos questions dont 33 nouvelles
La FAQ ASP.NET VB.NET : 277 réponses à vos questions dont 48 nouvelles

Que les amoureux du C++/CLI se rassurent, je continuerai toujours à m’occuper de la faq C++/CLI