Einer meiner Freunde (ein PHP-Entwickler) hat mir gesagt, dass C # nicht über die Kapazität für die Verwaltung von Ereignissen verfügt. Ereignisse werden nicht generiert oder nicht von C # -Codes gesteuert (Like Button Click , Selected Index Changing usw.). Es ist durch eine andere Skriptsprache wie JavaScript und er sagte mir seine JScript . Und dass alle Steuerelemente wie Beschriftungen und Schaltflächen clientseitig sind und nicht auf den Server gehen müssen.
Dann lautet meine Frage: Warum runat="server" für alle asp-Steuerelemente? Er sagte auch, dass die Umleitung (Response.Redirect) auch auf der Client-Seite passiert, seine nicht Server-Seite und C# haben nicht die Fähigkeit, dies zu tun, weil es ein PROGRAMMING LANGUAGE nicht ein SCRIPTING LANGUAGE .
Ich bin total verwirrt mit seiner Antwort und ich bin nicht mit seiner Antwort zufrieden. Kann mir jemand sagen, was es ist?
runat="server" ? Und was ist, wenn alle Steuerelemente clientseitig sind? Response.Redirect ? Ist es Client-Seite? Dann wie es funktioniert? ASP irgendeine Scripting language für events ? Ich bin neu bei C# . Vielleicht ist das eine schlechte Frage, aber kann jemand eine richtige Antwort geben? Ich bin total verwirrt.
Nach Ereignissen bedeutet Ereignisse wie Button_Click, SelectedIndexChanged usw.
Und ich erwähnte C # hier, weil ich C # verwende,
Danke
Es ist keine Sprache Sache, es ist ein Framework / Technologie-Ding. Zum Beispiel können ASP.net-Webformulare Ereignisse im Code ähnlich behandeln wie in einer Windows-Anwendung, aber es besteht nur darin, HTTP-Anfragen zu verpacken. In MVC (das auch C # ist), behandeln Sie Seitenereignisse, indem Sie mit dem Controller unter Verwendung Ihrer Standard-HTTP-Verben (get, post, put, delete usw.) interagieren.
Ich würde ihm sagen, dass php in diesem Fall keine Ereignisse behandelt. Da sowohl PHP als auch ASP serverseitige Sprachen sind, antworten sie alle auf HTTP-Anfragen, nicht auf Ereignisse. Aber Klicks sagen dem Browser, dass er Dinge tun und mit dem Server kommunizieren soll. Javascript würde mit Ereignissen umgehen und dann mit dem Server kommunizieren, aber der Punkt ist, sein Argument ist ein wenig durcheinander.
Andere Antworten:
Vielleicht möchten Sie etwas über die Grundlagen der Webentwicklung lernen. Genauer gesagt, wie http ist Statless und wie http Verben arbeiten. Es ist einfacher zu verstehen, was das Framework macht, wenn Sie verstehen, was passiert, wenn Sie kein Framework verwenden.
UPDATE: Nach den Änderungen habe ich Ihren Beitrag erneut gelesen und sehe, was das Problem ist. Dein Freund hat meistens Recht. C # ist keine Client-seitige Sprache, daher kann es nicht auf Seitenereignisse reagieren - also ist er dort richtig. Was ASP.net jedoch tut, ist Javascript, das diese Lücke überbrückt. Im Gegensatz dazu tut ASP / MVC das nicht, also müssten Sie das Javascript (oder auch nur grundlegende Formulareinreichungen) schreiben, die mit dem Controller sprechen würden, und dann müssten Sie die Antwort des Servers entsprechend behandeln.
>Er hat also Recht, Sie können nicht direkt C # -Code schreiben, um auf Seitenereignisse zu reagieren. Aber wenn Sie in C # mit ASP.net entwickeln, können Sie in C # programmieren und das notwendige Javascript für Sie generieren. Es wird aus Ihrer Sicht meist nahtlos sein.
Ich denke, vielleicht muss der Kontext der Unterhaltung, die Sie mit Ihrem Freund hatten, verstanden werden. Es scheint, Sie beziehen sich auf ASP.net nicht notwendig C # im Allgemeinen.
1. Was ist der Runat-Server? Und warum, wenn alle Steuerelemente clientseitig sind
Was in der ASP.net-Welt zu verstehen ist, ist der Unterschied zwischen Entwurfszeit, Serverseite und Clientseite. Im grundlegenden Lebenszyklus einer Seite würde der Compiler die Entwurfszeit-Seiten verwenden, um zu verstehen, wie ein Kontrollbaum auf der Serverseite aufgebaut wird. Steuerelemente, die als runat="server" gekennzeichnet sind, teilen dem Compiler mit, dass das Steuerelement als Teil des Designs einen Teil der Kontrollstruktur bilden muss, die auf dem Server erstellt wird.
2.Ist c # kann Redirect, Ereignisgenerierung, Handhabung etc.
Der Kontext ist hier wichtig. Ich vermute, wir sprechen nicht über C # im Allgemeinen eher ASP.net? ASP.net verwendet Ereignisse als die Möglichkeit, mit Anforderungen vom Server zu interagieren. Wenn Sie auf eine typische Seite in ASP.net klicken, fangen die clientseitigen JavaScript-Hooks das onlick-Ereignis ein und erstellen die Anforderung zum Senden an den Server. Die Seite wird dann die Argumente viewstate, event und event an den Server zurücksenden. Die Serverseite rekonstruiert den Kontrollbaum vom Viewstate und basierend auf den Event- und Event-Argumenten wird das entsprechende Event auf dem Server ausgelöst. Wenn Sie die serverseitigen Hooks für das Ereignis eingerichtet haben, werden Sie sie wie bei jedem Ereignis abfangen. Redirect wäre auch etwas, was im serverseitigen Code passiert.
3. Wenn c # nicht die Fähigkeit hat, welche Skriptsprache benutzt Windows? und wie es unabhängig vom Browser funktioniert
C # ist keine Skriptsprache, es ist kompiliert, naja ... der Kürze halber gehen wir damit um. ASP.net-Seiten sind in der Regel die Kombination aus C # serverseitigem Code und clientseitigem JavaScript-Code. Cient Seite würde Ereignisse abfangen und die Anfrage auf Serverseite übergeben.
4.und Was ist mit respose.redirect? ist es Client-Seite? dann wie es funktioniert
Response.redirect wäre serverseitig nicht clientseitig. Wenn Sie auf eine Seite des Seitenclients umleiten müssen, verwenden Sie Javascript window.location.href = '...'; oder etwas ähnliches
Kontext: Web ... sonst bist du sicher, dass er / sie ein Freund ist:)
Wie oben ist es nicht "die Sprache", es ist Ihre Wahl von ASP.net-Geschmacksrichtungen
Wenn es Web Forms ist, dann arbeitet ASP.Net mit Javascript auf der Client-Seite und welcher .net-Sprache auf der Serverseite (z. B. c #, vb)
Wenn es MVC / Razor ist, gibt es keine Abhängigkeit . Sie könnten alles auf der Server-Seite komplett per POST, GET usw. ausführen (nur sagen). Wenn man wollte, könnte man das auch in Web Forms machen ... nicht das sollte man:)
Umgekehrt könntest du auch eine 100% Javascript App machen (100% clientseitig) - natürlich mit dem Verständnis dafür (Einschränkungen, Sicherheitsüberlegungen etc.).