Search results matching tag 'ClientID'

AW: UserControl - Content von Seite in UserControl kopiert = Event wird nicht mehr gefeuert

Garry Cooper — Tue, 25 Aug 2009 14:26:14 GMT

Hallo,

auch dir sei Dank fürs Antworten!

Also das Javascript wird im ItemCreated Event gerendert. Allerdings mit schlechtesten Methoden -> Daher resultiert auch das Problem : Nach dem Postback wird die Seite nicht neu geladen sondern nur der Event neu Initialisiert und damit ist der _counter nicht bei -1.

Hat jemand vielleicht eine Methode um an den Index zu kommen (listView.Items.Count bleibt immer auf 0 - Dummerweise)

Also sollte ich entweder die Seite komplett neu laden - was wahrscheinlich am besten ist denn in dem UserControl werden Werte verändert die als Grundlage für Werte anderer Listen der Seite gelten.

Da wären wir gleich beim nächsten Problem - Wie lädt macht man denn einen Page Refresh aus einem UserControl herraus?

das ItemCreated Event auszugsweise:

private int _counter = -1; void listViewBookmarks_ItemCreated(object sender, ListViewItemEventArgs e) { _counter += 1; string textBoxTagsLocalID = null; textBoxTagsLocalID = "ctl00_ctl00_cphMstrMain_cphMstrDocuments_ctl00_listViewBookmarks_" + e.Item.ClientID + "_textboxTags"; PlaceHolder placeHolderDiv = (PlaceHolder) e.Item.FindControl("placeHolderDiv"); placeHolderDiv.Controls.Add( new LiteralControl("<div id=\"divBookmarkEditPanel" + _counter + "\" style=\" display:none;\">"));

c# ClientID mit Pfadangabe von MasterPages in einem ItemCreated Event ??

Garry Cooper — Tue, 25 Aug 2009 09:40:08 GMT

Hallo,

also ich fange in einem ListView ItemCreated Event eine Server TextBox ab und möchte die erzeugte ClientID mit Pfadangaben vom Master. Die ID von textBox.ClientID (z.B. "ctl001_textBox") enthält leider keinen Pfad?! Woher bekommt man die denn?

Zwei Ansätze wie mit den ClientIDs von ASP.NET umgegangen werden kann

Peter Bucher — Mon, 01 Sep 2008 22:57:00 GMT

Wie den meisten schon bekannt sein wird, erzeugt ASP.NET ClientIDs die auf dem Client genutzt werden können um Namenskollisionen aus dem Weg zu gehen.
Jedoch ist dieses Verhalten in manchen (Bei mir in den meisten Fällen) fehl am Platz und es ist mühselig die ClientIDs clientseitig zur Verfügung zu stellen.

Es gibt zwar, diese oder jene Lösung - jedoch war für mich keine wirklich zufriedenstellend.
Ich möchte euch Heute zwei Ansätze mit auf den Weg geben, damit die Arbeit mit Javascript und ASP.NET für euch nicht immer zur ID-Jagt wird.

Der erste Ansatz basiert unter anderem auf einer Idee von Renè Drescher-Hackel, auch ein ASP.NET Zone Genosse :)
Renè erstellt mithilfe von JSON ein Javascript Objekt, mit dem einfach auf die ClientIDs und ggf. noch weitere Eigenschaften zugegriffen werden kann.

ClientIdProvider mit einem HttpModule und statischen Hilfsmethoden

Ich wollte eine Lösung bei der ich möglichst wenig schreiben muss, nur das wichtigste bekomme und auch die Performance stimmt.
Die Lösung ist relativ einfach gehalten. Es braucht ein Methodenaufruf um ein Control für den Provider zu registrieren, danach steht die ClientID in Javascript automatisch über ClientId.<ControlName> bereit.

Dabei muss natürlich beachtet werden, dass nicht zwei gleichlautende Controls registriert werden.

Die Anwendung sieht dann so aus:

ASPX:

 

<ul> 
    <a href="#" onclick="addBorder('test');">Test1 (Div)</li> 
    <a href="#" onclick="addBorder(ClientId.pnlTest);">Test2 (Panel)</li> 
    <a href="#" onclick="addBorder(ClientId.pnlTest2);">Test3 (Panel)</li> 
</ul> 
<div id="test"> 
    test 
</div> 
<asp:Panel ID="pnlTest" runat="server"> 
    test2 
    <asp:Panel ID="pnlTest2" runat="server"> 
        test3 
    </asp:Panel> 
</asp:Panel>

Codebehind:

 

protected void Page_Load(object sender, EventArgs e) { 
    Tools.ClientIdProvider.RegisterControlForClientId(pnlTest); 
    Tools.ClientIdProvider.RegisterControlForClientId(pnlTest2); 
}

Das wars auch schon für den Anwender... nur was läuft dahinter ab?

Die Methode "RegisterControlForClientId(Control c)" speichert jeweils eine Referenz auf das Control
in einer Liste, die in der aktuellen HttpContext.Items Collection gespeichert ist.

Diese Liste ist vom Begin bis zum Ende des Requests unter dem Key (clientIdCollKey) verfügbar.
Um das JSON auf die Seite zu rendern, muss nur noch die Methode "WriteClientIdCollection(Page page)" zum richtigen Zeitpunkt aufgerufen werden.

Der richtige Zeitpunkt ist hier wichtig, genau ab Page_PreRender sind alle ClientIDs bestimmt vorhanden.
Also könnte diese Methode einfach in der überschrieben OnPreRender-Methode einer Seite aufgerufen werden.

Jedoch gibt das wieder Schreibarbeit und ist fehleranfällig.
Um dies zu automatisieren, kann ein HttpModule als Hilfe benutzt werden.

Die statischen Hilfsmethoden:

 

namespace pb.Web 
{ 
    public static partial class Tools 
    { 
        public static class ClientIdProvider 
        { 
            private const string clientIdCollKey = "pbclientIdColl"; 

            /// <summary> 
            /// Registriert ein Control für die ClientIdCollection, 
            /// sodass diese auf der Seite verfügbar ist. 
            /// </summary> 
            /// <param name="c">Das zu registrierende Control</param> 
            public static void RegisterControlForClientId(Control c) { 
                HttpContext context = HttpContext.Current; 
                object item = context.Items[clientIdCollKey]; 

                if (item == null || !(item is IList)) 
                    item = new List<Control>(); 

                (item as IList<Control>).Add(c); 

                context.Items[clientIdCollKey] = item; 
            } 

            /// <summary> 
            /// Schreibt die aktuelle ClientIdCollection in die 
            /// derzeitige Page Instanz 
            /// </summary> 
            public static void WriteClientIdCollection() { 
                WriteClientIdCollection(Tools.CurrentHandler<Page>()); 
            } 

            /// <summary> 
            /// Schreibt die aktuelle ClientIdCollection in die 
            /// derzeitige Page Instanz 
            /// </summary> 
            public static void WriteClientIdCollection(Page page) { 
                HttpContext context = HttpContext.Current; 
                object item = context.Items[clientIdCollKey]; 

                if (item == null) 
                    return; 

                IList<Control> list = (item as List<Control>); 
                StringBuilder sb = new StringBuilder(); 

                foreach (Control c in list) { 
                    sb.Append(""); 
                    sb.AppendFormat("\"{0}\" : \"{1}\"", c.ID, c.ClientID); 
                    sb.Append(","); 
                } 

                // TODO: Ab ASP.NET 3.5 kann hier stattdessen der 
                //TODO: System.Web.Script.Serialization.JavaScriptSerializer benutzt werden 
                page.ClientScript.RegisterStartupScript(page.GetType(), 
                                                                    "ClientId", 
                                                                    string.Format( 
                                                                    "\r\n var ClientId = new Object(); \r\n eval('ClientId = {{{0}}}');\r\n", 
                                                                    sb.ToString().Substring(0, sb.ToString().Length - 1)), 
                                                                    true); 
            } 
        } 
    } 
}

Das HttpModule ist ziemlich einfach aufgebaut, es hängt sich in den PreRequestHandlerExecute-Event,
ruft den aktuellen Handler ab und führt in dessen PreRender-Event die Methode der Tools-Klasse aus, um
das JSON zu rendern.

Somit geschieht alles vollautomatisch, es muss nur das HttpModule in der web.config registriert sein.

Das ClientIdProviderModule:

 

namespace pb.Web.HttpModules 
{ 
    /// <summary> 
    /// Registriert alle ClientIds als Startupscript in der aktuellen Page, 
    /// falls Controls registriert wurden. 
    /// </summary> 
    public class ClientIdProviderModule : XHttpModuleBase 
    { 
        protected override void _application_PreRequestHandlerExecute(object sender, EventArgs e) { 
            base._application_PreRequestHandlerExecute(sender, e); 

            IHttpHandler handler = Tools.CurrentHandler<IHttpHandler>(); 
            if (handler != null && handler is Page) { 
                Page page = handler as Page; 
                page.PreRender += delegate { 
                                                   Tools.ClientIdProvider.WriteClientIdCollection(page); 
                                               }; 
            } 
        } 
    } 
}

Beispiel web.config-Eintrag:

 

<?xml version="1.0"?> 
<configuration> 
    <system.web> 
        <httpModules> 
            <add name="ClientIdProviderModule" type="pb.Web.HttpModules.ClientIdProviderModule, ClientIdProviderTest"/> 
        </httpModules> 
    </system.web> 
</configuration>

Wichtig ist hier aber die Einschränkung auf Controls die alleinestehen, oder aber in einem TemplateInstance.SingleInstance - Template stehen.
Mit MultiInstance - Templates funktioniert diese Lösung nicht.

Zu Single- vs MultiInstance, siehe hier:

Überschreiben von IDs, damit diese gleich lauten wie die serverseitigen IDs

Wilco Bauwer, der unter anderem auch noch viele andere asp.nette Dinge auf seiner Seite anbietet,
hat ein Control entwickelt, dass die ClientIDs so überschreibt, dass sie gleich lauen wie die serverseitigen IDs.

Für manch ein Anwendungsfall ist das ein Muss und für die anderen vielfach eine gute Lösung mit wenig Aufwand.
Allerdings gilt auch hier, dass nur einzigartige IDs benutzt werden können, ansonsten kommt es zu einer Kollision.

http://www.wilcob.com/Wilco/News/AspNetIDOverride.aspx

Was ist jetzt besser?

Keine der beiden Lösungen ist besser.
Bei dem ClientIdProvider bestehen die ClientIDs immer noch genau gleich, jedoch gibt es clientseitig einen einfachen Zugriff darauf.
Beim ID-Overriding gibt es keine ClientIDs mehr bzw. die ClientID lautet gleich wie die ID auf dem Server. Das kann in vielen Szenarien Probleme verursachen (Bspw. Controls die IPostBackEventHandler implementieren funktionieren nicht mehr, etc...).

Daher gibt es keine Patentlösung, sondern jeweils für die Anforderung eine Lösung die passt.

Download des Beispielprojekts:

ClientIdProviderTest.zip

Benutzte Links:

Ein WebControl das keine ClientID rendert

Peter Bucher — Sun, 24 Feb 2008 13:54:00 GMT

Jedes Control das von der Klasse WebControl erbt, rendert automatisch ClientIDs in einem ID Attribut.
Dieses Rendering geschieht in der Methode AddAttributesToRender der Basisklasse WebControl.

Was nun tun, wenn keine ClientIDs in der Ausgabe erwünscht sind?

1. Die Eigenschaft ClientID überschreiben und null / String.Empty zurückgeben
2. Die Methode AddAttributesToRender übschreiben und dort Logik einbauen

Nummer 1. hat den Nachteil, dass das Attribut "id" immer noch gerendert wird, einfach mit keinem Inhalt -> fällt eher weg.
Nummer 2 ist genau das gesuchte, laut der Implementierung von WebControl wird das Attribut und dessen Wert weggelassen wenn die Eigenschaft ID null zurückgibt.

Resultat (Für ein HyperLink ohne ClientID Ausgabe):

/// <summary>
/// Ein HyperLink Control, das keine ClientIDs rendert
/// </summary>
public class HyperLinkClientIdLess : HyperLink {
    protected override void AddAttributesToRender(HtmlTextWriter writer) {
        string id = this.ID;
        this.ID = null;
        base.AddAttributesToRender(writer);
        this.ID = id;
    }
}

Wieso klappt das?
In der Methode der Basisklasse ist die Logik, die wir auch immer noch benötigen.
Diese Logik bringt uns das benötigte Verhalten, wenn ID == null ist.
Natürlich brauchen wir die ID später immer noch, deshalb wird sie einfach temporär (Für den Aufruf der Basismethode) auf null gesetzt.

Sinn / Unsinn?
Ich brauche das bspw. für ein Menu Control. Dort benötige ich keinen clientseitigen Zugriff auf die gerenderten Anker,
somit wären diese überflüssig.
Zudem lässt sich dieses Verhalten rein durch Austauschen des Klassennamens wieder rückgängig machen.

*Update
Ganz wichtig ist natürlich, das ein solches Unterfangen jeglichem Control, das Daten zurück an den Server senden
sollte / muss, diese Möglichkeit nimmt.
Ein Calendar Control, eine TextBox wird damit nicht mehr funktionieren bzw. nicht mehr über den normalen Mechanismus von ASP.NET.

Neue Möglichkeit
Aha, ich habe mich geirrt. Es gibt eine generische Lösung.
Bei meiner Lösung habe ich darauf geachtet, das die ID wiederhergestellt wird, jedoch wird diese sowieso nicht mehr benötigt.
Folgende Idee: http://www.vikramlakhotia.com/Removing_ID_of_controls_to_reduce_HTML_Size.aspx

D.h. man hängt sich in den PreRender Event irgend eines Control, Typ: "Control" ein, und setzt die ID auf null.
Bspw. so:

protected void Page_Load(object sender, EventArgs e) { this.<Control>.PreRender += this.DeleteId; } protected void DeleteId(object sender, EventArgs e) { (sender as Control).ID = null; }

IDs aller Labels auf der Seite entfernen

Und da diese Lösung nur auf den Typ Control angewiesen und deswegen generisch ist,
ergibt sich bspw. die Möglichkeit die ID aller Labels automatisch zu entziehen:

ControlCollection controls = <Alle Controls der Seite (Rekursiver Aufruf)>;
foreach(Control c in controls) {
    if(c is Label) {
        c.PreRender += this.DeleteId;
    }
}

AW: Mit JavaScript IDs ansprechen mit Masterpage&Runat=server

Peter Bucher — Mon, 11 Jun 2007 10:25:04 GMT

Hallo Julia

JuliaSchneider:
Ich programmiere noch nicht lange mit ASP.net, finde es aber jetzt schon beeindruckend was diese Technologie beispielsweise im Vergleich zu PHP zu leisten vermag :-)

Schön zu hören :-)

JuliaSchneider:

Interessanterweise funktioniert wiederrum auch mit Masterpage/Content-Element alles wenn ich das "runat=server" für die einzelnen Elemente wieder herausnehme.

Andersherum kann ich das "runat=server" problemlos benutzen wenn ich keine Masterpage/Content-Element benutze.

Kann sich jemand dieses "Phänomen" erklären? Wäre für jede Hilfe dankbar.

Ja, ASP.NET kennt drei verschiedene Arten für die Identifizierung von Controls, in deinem Fall musst du <Control>.ClientID benutzen.
Sobald ein Control bzw. ein Html Element mit runat="server" deklariert ist, werden die IDs bei Bedarf von ASP.NET automatisch generiert.

Eine Erklärung dazu findest du hier: Identifizierung von Controls: Control.ID / .ClientID / .UniqueID

Identifizierung von Controls: Control.ID / .ClientID / .UniqueID - UserControlTest

Peter Bucher — Mon, 09 Apr 2007 19:49:04 GMT

Control Identifizierung Beispiel

Peter Bucher — Mon, 09 Apr 2007 19:28:00 GMT

Artikel: Identifizierung von Controls: Control.ID / .ClientID / .UniqueID

Peter Bucher — Mon, 09 Apr 2007 17:46:00 GMT

ASP.NET Controls haben 3 verschiedene Eigenschaften, anhand dessen man sie identifizieren kann.
Na gut, man mag denken, desto mehr, desto besser :))

Es kann aber auch genau auch das Gegenteil bedeuten: Verwirrung.

Um die "Bösewichte" mal beim Namen zu nennen:
Serverseitige ID --> <Control>.ID
Clientseitige ID --> <Control>.ClientID
Clientseitiger Namen --> <Control>.UniqueID

Ein kleiner Exkurs zu Classic ASP um mehr über die Hintergründe zu erfahren.
In Classic ASP kann ein erweitertes HelloWorld Script so aussehen:

<form name="myForm" method="post">
    <input type="text" name="txtName" />
    <input type="submit" value="PostBack..." name="btnSubmit" />
</form>
<%
  If Request.Form.Count > 0 Then
      If Request.Form("txtName") <> vbNullString Then
          Response.Write("Hallo " & Request.Form("txtName") & "!")
      End If        
  End If
%>

Wir deklarieren hier alles von Hand und das genau so, wie es schliesslich beim Client ankommt.
Es wird der Name "txtName" für das Html Input Field manuell gesetzt und schliesslich auch für das anschliessende Request.Form benutzt.
Keine Probleme und eine heile Welt also :-)

Nun, was ist den überhaupt in ASP.NET so anders, dass wir hier drei verschiedene Eigenschaften zur Identifizierung eines Controls brauchen, werdet ihr euch wahrscheinlich fragen.
Es ist aber tatsächlich so, dass alle drei Eigenschaften ihre Berechtigung haben, hier also im einzeln:

Serverseitige ID --> <Control>.ID

Die serverseitige ID wird, wie der Name schon sagt, auf dem Server benutzt.

Bei deklerativen oder per Code erstellten Controls / Steuerelementen vergibt man manuell oder per Code automatisiert eine ID.
Diese dient bei der serverseitigen Arbeit zur eindeutigen Identifizierung der Controls.

Beim arbeiten mit ASP.NET benutzt man die meiste Zeit diese ID.
Wichtig zu wissen ist dabei, dass man durch die Schachtelung von Controls oder Schachtelung von Quellcode und Definierung von Namensräumen und Aliase, die jeweiligen IDs auch mehrmals vergeben kann, ohne dass dabei serverseitig die Eindeutigkeit verloren geht.

Schlussendlich wird die ganze Eindeutigkeit eben durch die Möglichkeiten auf dem Server (Schachtelung, Namensräume, Aliase) konsistent gehalten, ohne dass dabei Probleme entstehen.

Clientseitige ID --> <Control>.ClientID

Jetzt kommt die Kehrtwende, wir arbeiten ja nicht ausschliesslich auf dem Server, sondern wollen uns auch die Möglichkeiten auf dem Client nicht entgehen lassen.
Auf dem Client können wir mit Javascript oder VBScript (nur Internet Explorer) weiterarbeiten, ohne auf Rücksprache mit dem Server angewiesen zu sein.

Um überhaupt mit Javascript arbeiten zu können, müssen wir serverseitig den entsprechenden Code konstruieren und dem Client im Ausgabestrom zur Verfügung stellen.

Jetzt sieht die Situation mit den IDs schon wieder ganz anders aus.
Auf dem Client wird eine Html Seite (und evt. weitere Elemente) empfangen und verarbeitet. Im Gegensatz zum Server, haben wir hier keine Möglichkeiten mehr, von den oben genannten Vorteilen (Schachtelung, Namensräume, Aliase) zu profitieren.

ASP.NET wirkt diesem Problem entgegen, indem es, * bei Bedarf, für den Client aus den auf dem Server eindeutigen Namen / IDs, jeweils eindeutige Namen und IDs für den Client generiert.
So haben wir auf dem Server und auf dem Client jeweils eine eindeutige Namensumgebung ohne Konflikte.

* Wenn ein Control z.B. nur an die Page selber gehängt wird, kommen keine Präfixe in die ClientID bzw. UniqueID bzw. vor die normale ID.

Wollen wir jetzt clientseitig mit Javascript weiterarbeiten, kommt serverseitig zuerst <Control>.ClientID ins Spiel, diese Eigenschaft enthält die ID, die von ASP.NET automatisch generiert und zum Client gesendet wird.
Wir übergeben dem Javascript Code, der dann schlussendlich vom Server zum Client geschickt wird, jeweils die ClientID, die ASP.NET auch in den Html Quellcode rendert.
So können wir per Javascript auf die jeweiligen Controls clientseitig zugreifen.

Die clientseitige ID setzt sich aus dem Container- und dem eigentlichen Namen zusammen.
Beispielsweise ist in einem UserControl "uc1" ein Label "lblTest" enthalten, so lautet die ClientID: uc1_lblTest

Clientseitiger Namen --> <Control>.UniqueID

Am oberen Classic ASP Beispiel sehen wir, dass für die Übermittlung von Formularen mittels POST, das Name-Attribut eines Html Input Fields zur Identifizierung benutzt wird.
Die UniqueID ist im Grunde dasselbe wie die ClientID, nur dass man sich hier auf den Namen bzw. das Name-Attribut des Elementes bezieht und der Name anders codiert wird.

Die Zusammensetzung der ID ist identisch mit dem oberen Beispiel, nur dass zur Trennung der Namen, jeweils ein Dollarzeichen benutzt wird. UniqueID wird z.B. für den Fall benutzt, wenn man per Request.Form[] manuell einen Wert abrufen möchte.
Das Name-Attribut wird auf dem Client also wie folgt lauten: uc1$lblTest

Beispiel und Demonstration von Problemen die auftreten könnten

Ich habe für euch ein Beispiel zusammengestellt, das sowohl die Nutzung von serverseitigen IDs und UniqueID demonstriert, als auch im gleichen Atemzug auch ein mögliches Problem aufzeigt.

Im Beispiel verwende ich eine normale ASPX Seite mit Codebehind so wie auch ein UserControl das im Prinzip gleich aufgebaut ist, wie die ASPX Seite.
Die ASPX Seite bindet im unteren Bereich das UserControl ein.
Nicht nur der deklerative Teil, sondern auch der codierte, sieht praktisch gleich aus.
Auch die Benennung in Form von serverseitigen IDs ist zu Demonstrationszwecken völlig identisch.

Das Beispiel ist im Grunde gleich aufgebaut, wie das obere Classic ASP Beispiel.
Wir haben ein Formular, eine TextBox und ein Submit Button. Desweiteren sind auch noch ein paar Statuslabels vorhanden.

Man gibt seinen Namen ein und erhält ihn dann inklusive einer Begrüssung angezeigt, im UserControl, sowie auch auf der Seite.
Wenn man das Beispiel ausführt und bei beiden TextBoxen jeweils einen Wert eingibt, fällt gleich auf, dass bei der Ausgabe vom UserControl bei der Abfrage per Request.Form auf die <Control>.ID, den Wert vom Formular der ASPX Seite selber, angezeigt wird.

Der Grund ist einfach, wir haben serverseitig in der ASPX Seite, sowohl auch im UserControl identische Bezeichner, für unserer TextBoxen (und den ganzen Rest), wenn wir jetzt also versuchen clientseitig mithilfe der <Control>.ID auf den Wert zuzugreifen, fallen wir hier in einen Namenskonflikt.

Die Request.Form[] Abfrage per <Control>.ClientID bringt uns auch nicht weiter, da bei der Übertragung per POST auf die Namen zurückgegriffen wird und nicht auf die ID!

Hier ist <Control>.UniqueID also die Qual der Wahl, denn diese Eigenschaft liefert uns das automatisch generierte Name-Attribut des Controls.

Abschliessende Worte

Im Grunde benötigt man bei der Arbeit mit ASP.NET meistens nur ID oder die ClientID.
Request.Form sowie auch Response.Write sollte und benötigt man praktisch nicht mehr.

Das Modell von ASP.NET bietet hier viel komfortablere Möglichkeiten, anstelle von Response.Write() bieten sich Controls / Steuerelemente an, die man dynamisch per Inhalt füllen kann, z.B. <Control>.Text, etc..

Anstelle von Request.Form[] kann man im Code einfach auf die .Text Eigenschaft der TextBoxen zugreifen.
So wird die ganze Arbeit mit der Identifizierung der Controls von ASP.NET gehandelt und vereinfacht.
Siehe auch: Die alten Bekannten - Response.Write() und Request.Form[]

Möglichkeiten um Javascript die ClientID eines Controls bekanntzumachen, finden sich auf folgender Seite:

Zwei Ansätze wie mit den ClientIDs von ASP.NET umgegangen werden kann

Beispielprojekt:

UserControlTest.zip

MSDN Links:

Dank geht an Kai Gloth für die Idee zum Artikel, sowie den Hinweis zu <Control>.UniqueID im Bezug auf Request.Form[]

Bearbeitung / Korrekturen:
23.05.07 - Hinweis zum generieren bzw. nichtgenerieren der IDs hinzugefügt
28.11.07 - Link zum Codeclip von Daniel Walzenbach hinzugefügt
17.03.08 - Link zu "Die alten Bekannten - Response.Write() und Request.Form[]" hinzugefügt