Perché i moduli Web ASP.NET hanno bisogno dell'attributo Runat = "Server"?

Perché devo specificare runat="server"su tutti i miei controlli ASP.NET quando è un attributo obbligatorio ed serverè l'unica opzione disponibile nella mia conoscenza limitata di ASP.NET e ottengo un errore se non lo uso?

Capisco che posso opzionalmente usarlo sui miei tag HTML e capisco il paradigma client / server e cosa sta effettivamente specificando.

È un tag ridondante che potrebbe essere sottinteso dal fatto che il controllo è un controllo ASP.NET o c'è un motivo sottostante?

Ho sempre creduto che ci fosse di più per capire che puoi mescolare tag ASP.NET e tag HTML e i tag HTML hanno l'opzione di essere runat="server"o meno. Non lasciare nulla a lasciare il tag dentro e provoca un errore del compilatore per eliminarlo. Maggiore è il significato del linguaggio Web, meno è facile per un programmatore in erba entrare e apprenderlo. Questo è un motivo valido come uno per essere prolisso sugli attributi dei tag.

Questa conversazione si è svolta sul blog di Mike Schinkel tra lui e Talbot Crowell di Microsoft National Services. Le informazioni pertinenti sono di seguito (primo paragrafo parafrasato a causa di errori grammaticali nella fonte):

[...] ma l'importanza di <runat="server">è maggiore per coerenza ed estensibilità.

Se lo sviluppatore deve contrassegnare alcuni tag (vale a dire <asp: />) affinché il motore ASP.NET ignori, allora c'è anche il potenziale problema delle collisioni dello spazio dei nomi tra tag e miglioramenti futuri. Richiedendo l' <runat="server">attributo, questo viene negato.

Continua:

Se <runat=client>fosse richiesto per tutti i tag lato client, il parser avrebbe dovuto analizzare tutti i tag e rimuovere la <runat=client>parte.

Lui continua:

Attualmente, se la mia ipotesi è corretta, il parser semplicemente ignora tutto il testo (tag o nessun tag) a meno che non sia un tag con l' runat=serverattributo o un " <%" prefisso o ssi " <!– #include... (...) Inoltre, poiché ASP.NET è progettato per consentire la separazione dei web designer (foo.aspx) dagli sviluppatori web (foo.aspx.vb), i web designer possono utilizzare i propri strumenti di web designer per posizionare HTML e JavaScript lato client senza dover conoscere ASP.NET tag o attributi specifici.

Di solito non mi piace indovinare, ma ho intenzione di questo ...

Se ricordi l'hype di marketing .NET di Microsoft nel passato (2001?), Era difficile dire cosa fosse .NET. Era un server? una piattaforma di programmazione? una lingua? qualcosa di completamente nuovo? Date le pubblicità, era ambiguamente qualsiasi cosa tu volessi che fosse - ha appena risolto qualsiasi problema che potresti avere.

Quindi, suppongo che ci fosse una visione nascosta che il codice ASP.NET potesse essere eseguito ovunque - lato server o lato client, in una copia di Internet Explorer legata al runtime .NET. runat = "server" è solo un residuo vestigiale, lasciato alle spalle perché il suo equivalente lato client non è mai arrivato alla produzione.

Ricordi quelle strane pubblicità?

Correlati: articolo dal registro con un po 'di storia .NET.

Non tutti i controlli che possono essere inclusi in una pagina devono essere eseguiti sul server. Per esempio:

<INPUT type="submit" runat=server />

Questo è essenzialmente lo stesso di:

<asp:Button runat=server />

Rimuovi il tag runat = server dal primo e hai un pulsante HTML standard che viene eseguito nel browser. Esistono ragioni a favore e contro l'esecuzione di un controllo specifico sul server e ASP.NET non può in alcun modo "assumere" ciò che si desidera in base al markup HTML incluso. Potrebbe essere possibile "inferire" il server runat = per la <asp:XXX />famiglia di controlli, ma la mia ipotesi è che Microsoft considererebbe un hack alla sintassi di markup e al motore ASP.NET.

Articolo di Microsoft Msdn I controlli dimenticati: i controlli server HTML spiegano l'uso di runat = "server" con un esempio nella casella di testo <input type="text">convertendolo in<input type="text" id="Textbox1" runat="server">

In questo modo avrai accesso a livello di codice all'elemento HTML sul server prima che la pagina Web venga creata e inviata al client. L'elemento HTML deve contenere un attributo id. Questo attributo funge da identità per l'elemento e consente di programmare gli elementi in base ai loro ID specifici. Oltre a questo attributo, l'elemento HTML deve contenere runat = "server". Ciò indica al server di elaborazione che il tag viene elaborato sul server e non deve essere considerato un elemento HTML tradizionale.

In breve, per consentire l'accesso a livello di codice all'elemento HTML aggiungerlo runat="server"ad esso.

Il mio sospetto è che abbia a che fare con il modo in cui i controlli lato server vengono identificati durante l'elaborazione. Invece di dover controllare ogni controllo in fase di esecuzione per nome per determinare se è necessario eseguire l'elaborazione sul lato server, effettua una selezione sulla rappresentazione del nodo interno tramite tag. Il compilatore verifica che tutti i controlli che richiedono tag del server li abbiano durante il passaggio di convalida.

Gli elementi HTML nei file ASP.NET sono, per impostazione predefinita, trattati come testo. Per rendere programmabili questi elementi, aggiungi un runat="server"attributo all'elemento HTML. Questo attributo indica che l'elemento deve essere trattato come un controllo server.

È lì perché tutti i controlli in ASP .NET ereditano da System.Web.UI.Control che ha l'attributo "runat".

nella classe System.Web.UI.HTMLControl, l'attributo non è richiesto, tuttavia nella classe System.Web.UI.WebControl l'attributo è richiesto.

modifica: lasciami essere più specifico. poiché asp.net è praticamente un estratto di HTML, il compilatore ha bisogno di una sorta di direttiva in modo che sappia che tag specifici devono funzionare sul lato server. se quell'attributo non fosse presente, non è in grado di elaborarlo prima sul server. se non è presente, presuppone che sia un markup regolare e lo passa al client.

Penso che Microsoft possa risolvere questa ambiguità facendo in modo che il compilatore aggiunga l'attributo runat prima che la pagina venga mai compilata, qualcosa come la cosa di cancellazione del tipo che ha Java con i generici, invece di cancellare, potrebbe scrivere runat = server dove vede asp: prefisso per i tag, quindi lo sviluppatore non dovrebbe preoccuparsene.

Se lo usi su normali tag html, significa che puoi manipolarli a livello di codice nei gestori di eventi ecc., Ad es. Cambiare l'href o la classe di un tag di ancoraggio al caricamento della pagina ... fallo solo se devi, perché tag html vanilla vai più veloce.

Per quanto riguarda i controlli utente e i controlli server, no, semplicemente non funzioneranno senza di loro, senza aver scavato nelle viscere del preprocessore aspx, non saprei dire esattamente il perché, ma indovinerebbero che, probabilmente per buone ragioni, hanno appena scritto il parser in quel modo, cercando cose esplicitamente contrassegnate come "fai qualcosa".

Se @JonSkeet è ovunque, probabilmente sarà in grado di fornire una risposta molto migliore.

Quando si inviano i dati al server Web ASP.NET, i controlli indicati come Runat = "server" saranno rappresentati come oggetti Dot Net nell'applicazione server. È possibile digitare manualmente il codice nei controlli HTML oppure utilizzare l' opzione Esegui come server facendo clic con il pulsante destro del mouse in visualizzazione struttura. I controlli ASP.NET ottengono automaticamente questo attributo quando lo trascini dalla casella degli strumenti, in genere i controlli HTML no.

Attributo piuttosto ridondante, considerando che il tag "asp" è ovviamente un elemento ASP e dovrebbe essere sufficiente per identificarlo come elemento accessibile sul lato server.

Altrove, tuttavia, veniva utilizzato per elevare i normali tag da utilizzare nel code-behind.

Sono appena giunto a questa conclusione per tentativi ed errori: runat = "server" è necessario per accedere agli elementi in fase di esecuzione sul lato server. Rimuovili, ricompila e guarda cosa succede.

runat="Server" indica che si verificherà un postback sul server per il "controllo" HTML.

I moduli Web utilizzano postbackcostantemente per segnalare al server di elaborare un evento di controllo della pagina.

.NET MVCle pagine NON usano postback(tranne che per un modulo "submit"). MVCsi affida JQUERYalla gestione della pagina sul lato client (evitando così la necessità di molti postbackmessaggi al server).

Quindi: .NETWeb Form ... usa molto l' "runat"attributo nel markup della pagina.

.NET MVCquasi mai usa l' "runat"attributo nel markup della pagina.

Spero che questo aiuti a chiarire perché runatè necessario ...