Controlli rispetto a HTML standard
https://stackoverflow.com/questions/22084
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Sto entrando in ASP.NET (C# - so che non ha importanza per questa domanda particolare, ma la divulgazione completa e tutto il resto), e anche se mi piace che asp:I controlli in stile mi risparmiano un sacco di noiose creazioni HTML, spesso sono frustrato da determinati comportamenti.Ne ho incontrato uno ieri sera mentre lavoravo con le Pagine Master:Mio <asp:BulletedList ID="nav">, una volta convertito in HTML, diventava <ul id="ct100_nav">.
Ci sono altri problemi: ho notato che quando compili automaticamente un DataGrid, aggiunge attributi alla tabella risultante che non necessariamente desidero lì.
So che esiste una certa "convenzione sulla configurazione" che devi accettare quando fai affidamento su un framework per assumere alcuni dei tuoi noiosi compiti, ma le "convenzioni" in questi casi non sono tanto convenzioni stabilite , ma piuttosto extra inutili.Lo so Perché l'ID aggiunge il prefisso, ma dovrei essere in grado di modificare e disattivare cose del genere, soprattutto perché, essendo un po' un evangelista degli standard web, non duplico comunque gli ID HTML in una singola pagina.
Quindi la domanda qui è per quegli sviluppatori ASP.NET più esperti di me:nelle tue esperienze nello sviluppo e nella distribuzione di app, come sfrutti questi controlli?Ti ritrovi a ricorrere nuovamente all'HTML hardcoded?Usi una miscela?Non voglio progettare il mio HTML attorno a stranezze idiosincratiche in questi controlli, ma, se possibile, mi piacerebbe sfruttarli quando possibile.
Cosa deve fare un ragazzo?
Soluzione
Personalmente,
Penso che i controlli ASP.NET standard vadano bene per le cose interne: veloce e sporco è buono in quello scenario.Ma una volta ho lavorato con uno sviluppatore web che era anche un designer e si è rifiutato di utilizzare i controlli ASP.NET e solo il codice in HTML e di aggiungere tag runat="server" quando necessario.Ciò era dovuto al fatto che voleva sapere esattamente come sarebbe stato eseguito il rendering del suo HTML e, comunque, in quel momento, alcuni controlli ASP.NET non sarebbero stati renderizzati in conformità agli standard.
Mi siedo da qualche parte nel mezzo: usa l'HTML dove appropriato e non quando no.Puoi ottenere il meglio di entrambi i mondi con il Adattatori di controllo CSS
Altri suggerimenti
In realtà sono piuttosto sollevato nel vedere alcune opinioni qui in accordo con le mie:ASP.NET come linguaggio modello è molto scarso.
Vorrei solo confutare un paio di punti a favore espressi qui (tuta antincendio addosso!):
Dave Ward menziona le collisioni di documenti d'identità: questo è vero, ma per quanto sia gestito male.Avrei preferito vedere i nodi a cui fa riferimento xpath o selettori CSS profondi piuttosto che rendere l'ID effettivamente inutile se non rimandando agli interni ASP.NET come clientID: rende semplicemente la scrittura di CSS e JS molto più difficile inutilmente.
Rob Cooper parla di come i controlli sostituiscono l'HTML quindi va tutto bene (parafrasando, perdonami Rob) - beh non va bene, perché hanno preso un linguaggio esistente e ben compreso e hanno detto "no, devi fare le cose a modo nostro adesso", e il loro modo è molto mal implementato.per esempio.asp:panel esegue il rendering di una tabella in un browser e di un div in un altro!Senza documentazione o esecuzione, il markup per un controllo di accesso (e molti altri) non è prevedibile.Come farai a convincere un designer a scrivere CSS contro questo?
Espo scrive di come i controlli ti danno i vantaggi dell'astrazione se la piattaforma cambia l'html - beh, questo è chiaramente circolare (sta cambiando solo perché la piattaforma sta cambiando, e non ce ne sarebbe bisogno se invece avessi solo il mio HTML) e crea effettivamente un problema.Se il controllo cambierà di nuovo con gli aggiornamenti, come farà il mio CSS a gestirlo?
Gli apologeti diranno "sì, ma puoi cambiarlo nella configurazione" o parleranno di controlli prioritari e controlli personalizzati.Ebbene, perché dovrei farlo?Il pacchetto di controlli CSS friendly pensato per risolvere alcuni di questi problemi è tutt'altro che con il suo markup non semantico e non risolve il problema dell'ID.
È impossibile implementare MVC (il concetto astratto, non l'implementazione 3.5) immediatamente con le app dei moduli Web perché questi controlli legano così strettamente la visualizzazione e il controllo.Ora c'è una barriera d'ingresso per il web designer tradizionale perché deve essere coinvolto nel codice lato server per implementare quelli che erano i domini separati di CSS e JS.Sono solidale con queste persone.
Sono assolutamente d'accordo con il punto di Kiwi secondo cui i controlli consentono uno sviluppo molto rapido per app di un determinato profilo e accetto che per qualsiasi motivo alcuni programmatori trovino HTML sgradevole e inoltre che i vantaggi offerti dalle altre parti di ASP.NET, che richiede questi controlli, Maggio valere il prezzo.
Tuttavia, IO risentito per la perdita di controllo, ritengo che il modello di gestione di cose come classi, stili e scripting sul codebehind sia un passo indietro sbagliato e ritengo inoltre che esistano modelli migliori per il template (implementazione di microformati e xslt per questa piattaforma) sebbene sostituire i controlli con questi non sia banale.
Penso che ASP.NET potrebbe imparare molto dalla tecnologia correlata nel mondo LAMP e dei binari, fino ad allora spero di lavorare con 3,5 MVC dove posso.
(scusate se sono stato così lungo </rant>)
La risposta breve è che non dovresti mai usare un aspide:...versione di un controllo HTML standard a meno che tu non abbia una ragione veramente valida.
Gli sviluppatori junior spesso vengono indotti a utilizzare questi controlli perché sono trattati nella maggior parte dei libri ASP.NET, quindi si presume che debbano essere migliori.Loro non sono.A questo punto, dopo 8 anni di sviluppo quotidiano di ASP.NET, posso pensare solo a 2 o 3 casi in cui ha effettivamente senso utilizzare un asp:...Controllo INPUT su uno standard HTML.
Per quanto riguarda gli ID sui controlli server:Puoi trovare l'ID effettivo che verrà scritto nel browser accedendo a ClientID.In questo modo puoi combinare script lato server e lato client senza dover comunque codificare _id="ct100_nav"_
Cerco sempre di utilizzare i controlli inclusi invece di "hackerare" l'HTML, perché se c'è un aggiornamento o qualche miglioramento in seguito, tutto il mio codice continuerà a funzionare semplicemente sostituendo il framework e non devo modificare alcun codice HTML.
Spero che questo ti aiuti
@Brian, sì!Puoi praticamente controllare tutto il comportamento..Considera la possibilità di creare controlli personalizzati (ce ne sono tre tipi).Recentemente ne ho fornito una panoramica nella mia domanda Qui.
Vorrei fortemente consiglio di provarli, mi ha aiutato moltissimo :)
Anch'io sono nella mia avventura in ASP.NET e ho avuto anch'io frustrazioni simili.Tuttavia ci si abitua presto.Devi solo ricordare, il motivo per cui non hai la noiosa creazione di HTML è perché i controlli ASP.NET fanno tutto per te.
In una certa misura puoi controllare/modificare queste cose, anche se ciò significa ereditare il controllo e modificare l'output HTML da lì.
Ho dovuto farlo in passato, quando alcuni controlli non superavano la convalida W3C per impostazione predefinita inserendo qualche markup aggiuntivo qua e là, quindi ho semplicemente sovrascritto e modificato secondo necessità (una correzione che richiede letteralmente un paio di minuti).
Direi di informarsi su come funziona il sistema di controlli..Quindi mettine insieme alcuni tu stesso, questo mi ha davvero aiutato a capire cosa succede sotto il cofano, quindi se mai dovessi avere problemi, ho un'idea a cui rivolgermi.
L'HTML viene visualizzato con questo tipo di ID perché è il modo in cui ASP.NET impedisce le collisioni di ID.Ogni controllo contenitore, ad esempio una pagina master o un controllo guidata, anteporrà un "ID_" agli ID dei relativi figli.
Nel caso del tuo elenco puntato, ListView fornisce una bella via di mezzo.Puoi comunque associarlo a un'origine dati, ma ti dà un controllo molto più stretto sull'HTML renderizzato.Scott Gu ha una bella introduzione a ListView qui:
Se il prefisso dell'ID aggiunto da ASP.NET è un problema per te accedervi in seguito utilizzando JS o qualcosa del genere...hai il lato server della proprietà .ClientID.
Se il sovraccarico aggiunto da ASP.NET dovresti considerare ASP.NET MVC (ancora anteprima) dove hai il pieno controllo sull'HTML emesso.
Sto passando a MVC perché non mi piacciono tutte quelle cose aggiunte....
Penso che la maggior parte delle risposte qui prendano il punto di vista di un designer.In un progetto di piccole e medie dimensioni potrebbe sembrare un sovraccarico sincronizzare codice e CSS/HTML e renderli conformi agli standard e puliti.Il modo in cui un designer riesce a farlo è avere il pieno controllo sull'HTML renderizzato.Ma esistono molti modi per avere il pieno controllo in ASP.NET.E per me, avere l'HTML richiesto nel file aspx/ascx è il modo meno scalabile e sporco per farlo.Se desideri dare uno stile ai controlli tramite CSS, puoi sempre impostare una classe lato server tramite la proprietà CssClass.Se desideri accedervi tramite JS, puoi emettere nuovamente il JS con gli ID corretti sul lato server.L'unico svantaggio che ciò comporta è che uno sviluppatore e un designer devono lavorare insieme a stretto contatto.In qualsiasi progetto di grandi dimensioni questo è comunque inevitabile.Ma i vantaggi offerti da ASP.NET superano di gran lunga queste difficoltà.Tuttavia, se desideri HTML conforme agli standard, supporto per skin e altre funzionalità per controllare il markup renderizzato, puoi sempre utilizzare controlli di terze parti.
Come ha già menzionato Dave Ward, "è il modo in cui ASP.NET impedisce le collisioni di ID".
Un ottimo esempio di ciò è se stai tentando di inserire un controllo all'interno di un controllo personalizzato, quindi utilizzare quel controllo personalizzato in un ripetitore, in modo che l'HTML del controllo personalizzato venga visualizzato più volte per la pagina.
Come altri hanno già detto, se devi accedere ai controlli per JavaScript, utilizza la proprietà ClientScript che ti darà accesso a ClientScriptManager e registrerai i tuoi script nella pagina in questo modo.Assicurati quando scrivi i tuoi script di utilizzare la proprietà ClientID sul controllo a cui stai tentando di fare riferimento invece di digitare semplicemente l'ID del controllo.
Se vuoi avere così tanto controllo sull'HTML renderizzato, esamina ASP.NET MVC Invece.
