2008-12-16 2 views
46

Diese Frage ist ein Ergebnis dessen, was ich beim Versuch zu beantworten another question bemerkt habe. Und jetzt bin ich neugierig zu wissen, warum <asp:TextBox runat="server" Visible="<%= true %>" /> zu einem Kompilierungsfehler führt, und nicht zu einem sichtbaren TextBox, wie ich es erwartet hätte.Warum werden <%= %> Ausdrücke als Eigenschaftswerte auf einem Server-Steuerelement zu einem Kompilierungsfehler führen?

Von dem, was ich bisher entdeckt habe, werden die <%= %> Ausdrücke nicht in literale Kontrollen übersetzt, wie ich immer gedacht habe. Stattdessen wird es ausgewertet und direkt in den HtmlTextWriter geschrieben, wenn die Seite gerendert wird. Aber anscheinend versucht der Parser (ich bin nicht sicher, ob das der richtige Ausdruck für den Teil ist, der ASP.NET-Markup in .NET-Code übersetzt) ​​nicht einmal <%= %> Ausdrücke auszuwerten, wenn sie als Eigenschaftswerte für Serversteuerelemente verwendet werden. Es verwendet es nur als Zeichenfolge. Was ich vermute, ist, warum ich die Fehlermeldung: kann kein Objekt des Typs 'System.Boolean' aus seiner Zeichenfolgendarstellung '<% = True%>' für die Eigenschaft 'Sichtbar' erstellen.

Wenn ich stattdessen den Runat Graben = „Server“ und kombiniert die <%= %> mit regelmäßigen HTML-Markup, wie folgt aus:

<input type="button" id="Button1" visible='<%= true %>' /> 

Dann wird der Parser nur die Brocken in Teile aufteilt vor und nach dem Ausdruck und dann schreibt es in den HtmlTextWriter in der Rendermethode. Etwas wie folgt aus:

__w.Write("<input type=\"button\" id=\"Button1\" visible='"); 
    __w.Write(true); 
    __w.Write("' />"); 

Als letzte Sache, die ich bemerkt, ... Wenn ich versuche, mit <%# %> + Control.DataBind(), dann bekomme ich, was ich erwarten würde. Es verknüpft den zu verwendenden Ausdruck, wenn das Steuerelement datengebunden ist. Im Gegensatz zum Ausdruck <% =%> wertet der generierte Code jedoch den Inhalt des Ausdrucks <%# %> aus. Der Parser endet Erzeugen der folgende:

[DebuggerNonUserCode] 
private Button __BuildControldataboundButton() 
{ 
    Button button = new Button(); 
    base.databoundButton = button; 
    button.ApplyStyleSheetSkin(this); 
    button.ID = "databoundButton"; 
    button.DataBinding += new EventHandler(this.__DataBindingdataboundButton); 
    return button; 
} 

public void __DataBindingdataboundButton(object sender, EventArgs e) 
{ 
    Button button = (Button) sender; 
    Page bindingContainer = (Page) button.BindingContainer; 
    button.Visible = true; 
} 

Von:

<asp:Button ID="databoundButton" Visible='<%# true %>' runat="server" /> 

Beachten Sie die button.Visible = true;, die das Ergebnis der <%# %> Ausdruck ist.

Also meine Frage ist .. Warum ist der Ausdruck im ersten Beispiel nur als eine Zeichenfolge behandelt, anstatt zu "wahr" ausgewertet werden. Die Ausdrücke sind für die beiden anderen Beispiele etwas ähnlich, und sie ergeben den Code, den ich erwartet hätte.

Ist es nur ein Fehler (was ich bezweifle, da es kein neues Problem mit der aktuellen Version von ASP.NET ist), oder gibt es einen guten Grund, warum wir <%= %> nicht so verwenden dürfen? Diese

Antwort

90

:

<asp:Button runat="server" id="Button1" visible='<%= true %>' /> 

nicht ausgewertet dazu:

<asp:Button runat="server" id="Button1" visible='true' /> 

<% =%> gibt direkt in den Antwortstream und der asp-Markup ist nicht Teil der Antwortstream. Es ist ein Fehler anzunehmen, dass die <% =%> - Operatoren irgendeine Art von Vorverarbeitung auf dem ASP-Markup durchführen.


Nebenbei hilft es, über den ASP nachzudenken.NET-Lebenszyklus in Bezug auf die Operatoren <% #%> und <% =%>.

  • <% #%> hat Semantik mehr gemeinsam mit einem Wert zu einem Objekt zugeordnet wird. Im ASP.NET-Lebenszyklus werden die Operatoren <% #%> ausgewertet, bevor die Seite das erste Byte in den Antwortpuffer schreibt.

  • <% =%> bedeutet das Gleiche wie Response.Write. Wir müssen zuerst alle unsere Datenbindungs- und Formularverarbeitungen durchführen und am Ende des ASP.NET-Lebenszyklus HTML in den Antwortpuffer ausgeben.

+0

Danke, macht Sinn, es passt zu dem, was ich in Reflector sah. Ich glaube, ich hatte gehofft, dass der "Response.Write" -Effekt nur eine Konsequenz dessen war, wie ich ihn benutzt habe, und nicht, wie er funktioniert hat. –

+11

+1 Hatte diese Antwort zweimal zu lesen, um den Punkt zu fangen: ** Ausgänge direkt in den Antwortstream und der asp-Markup ist Teil der Antwortstream nicht ** aka, '' <%=true%> nicht am Ende in dem ' Andomar

+0

Sie müssen auch Button1.DataBind() in Pageload-Methode aufrufen –

Verwandte Themen