Controles versus HTML padrão
https://stackoverflow.com/questions/22084
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Estou entrando no ASP.NET (C# - eu sei que não importa para esta questão em particular, mas divulgação completa e tudo mais), e embora eu ame isso, o asp:Os controles de estilo me poupam de muitos trabalhos tediosos de criação de HTML; muitas vezes fico frustrado com certos comportamentos.Encontrei um ontem à noite ao trabalhar com páginas mestras:meu <asp:BulletedList ID="nav">, quando convertido em HTML, tornou-se <ul id="ct100_nav">.
Existem outros problemas - notei que quando você preenche automaticamente um DataGrid, ele adiciona atributos à tabela resultante que eu não necessariamente quero lá.
Eu sei que há uma certa quantidade de "convenção sobre configuração" que você tem que aceitar quando depende de uma estrutura para assumir algumas de suas tarefas tediosas, mas as "convenções" nesses casos não são tanto convenções estabelecidas , mas extras desnecessários.Eu sei por que o ID adiciona o prefixo, mas eu deveria ser capaz de ajustar e desativar coisas assim, especialmente porque, como um evangelista de padrões da web, eu não duplico IDs de HTML em uma única página.
Portanto, a questão aqui é para os desenvolvedores de ASP.NET mais experientes que eu:em suas experiências no desenvolvimento e implantação de aplicativos, como você aproveita esses controles?Você está recorrendo ao HTML codificado?Você usa uma mistura?Não quero projetar meu HTML em torno de peculiaridades idiossincráticas desses controles, mas, se possível, gostaria de aproveitá-los quando possível.
O que um menino deve fazer?
Solução
Pessoalmente,
Acho que os controles padrão do ASP.NET são bons para coisas internas - rápido e sujo é bom nesse cenário.Mas, uma vez, trabalhei com um desenvolvedor web que também era designer e ele se recusou a usar os controles ASP.NET e apenas codificar em HTML e adicionar tags runat = "server" quando necessário.Isso ocorreu mais porque ele queria saber exatamente como seu HTML seria renderizado e, de qualquer maneira, na época, alguns dos controles do ASP.NET não seriam renderizados de acordo com os padrões.
Sento-me em algum lugar no meio - use HTML quando apropriado e não quando não.Você pode ter o melhor dos dois mundos com o Adaptadores de controle CSS
Outras dicas
Na verdade, estou bastante aliviado ao ver algumas opiniões aqui concordando com as minhas:ASP.NET como linguagem de modelo é muito pobre.
Eu gostaria apenas de refutar alguns dos pontos profissionais mencionados aqui (traje flamejante!):
Dave Ward menciona colisões de ID - isso é verdade, mas como foi mal tratado.Eu teria preferido ver nós referenciados por xpath ou seletores CSS profundos do que tornar o ID efetivamente inútil, exceto adiando os componentes internos do ASP.NET como clientID - isso apenas torna a escrita de CSS e JS muito mais difícil inutilmente.
Rob Cooper fala sobre como os controles substituem o HTML, então está tudo bem (parafraseando, me perdoe Rob) - bem, não está bem, porque eles pegaram uma linguagem existente e bem compreendida e disseram "não, você tem que fazer as coisas do nosso jeito agora", e o caminho deles é muito mal implementado.por exemplo.asp:panel renderiza uma tabela em um navegador e uma div em outro!Sem documentação ou execução, a marcação para um controle de login (e muitos outros) não é previsível.Como você fará com que um designer escreva CSS contra isso?
Espo escreve sobre como os controles oferecem os benefícios da abstração se a plataforma alterar o html - bem, isso é claramente circular (só está mudando porque a plataforma está mudando e não precisaria se eu tivesse meu próprio HTML lá) e na verdade cria um problema.Se o controle mudar novamente com as atualizações, como meu CSS deve lidar com isso?
Os apologistas dirão "sim, mas você pode alterar isso na configuração" ou falarão sobre a substituição de controles e controles personalizados.Bem, por que eu deveria fazer isso?O pacote de controles compatíveis com CSS destinado a corrigir alguns desses problemas é tudo menos sua marcação não semântica e não resolve o problema de ID.
É impossível implementar o MVC (o conceito abstrato, não a implementação 3.5) imediatamente com aplicativos de formulário da web, porque esses controles vinculam fortemente a visualização e o controle.Há uma barreira de entrada para o web designer tradicional agora porque ele precisa se envolver com o código do lado do servidor para implementar o que costumavam ser domínios separados de CSS e JS.Eu simpatizo com essas pessoas.
Concordo plenamente com o argumento do Kiwi de que os controles permitem um desenvolvimento muito rápido para aplicativos de um determinado perfil e aceito que, por qualquer motivo, alguns programadores consideram o HTML desagradável e, além disso, as vantagens que outras partes do ASP.NET oferecem, que exige esses controles, poderia valer a pena o preço.
No entanto, EU ressinto-me da perda de controle, sinto que o modelo de lidar com coisas como classes, estilos e scripts no codebehind é um retrocesso equivocado e sinto ainda que existem modelos melhores para modelagem (implementação de microformatos e xslt para esta plataforma) embora substituir os controles por estes não seja trivial.
Acho que o ASP.NET poderia aprender muito com a tecnologia relacionada no mundo LAMP e Rails, até então espero trabalhar com 3.5 MVC onde puder.
(desculpe, demorou tanto </rant>)
A resposta curta é que você nunca deve usar um asp:...versão de um controle HTML padrão, a menos que você tenha um bom motivo.
Os desenvolvedores juniores muitas vezes são levados a usar esses controles porque eles são abordados na maioria dos livros sobre ASP.NET, portanto, presume-se que eles devem ser melhores.Eles não são.Neste ponto, após 8 anos de desenvolvimento diário do ASP.NET, só consigo pensar em 2 ou 3 casos em que realmente faz sentido usar um asp:...Controle INPUT sobre um HTML padrão.
Quanto aos IDs nos controles do servidor:Você pode encontrar o ID real que será gravado no navegador acessando ClientID.Dessa forma, você pode combinar scripts do lado do servidor e do lado do cliente e ainda não precisa codificar _id="ct100_nav"_
Eu sempre tento usar os controles incluídos em vez de "hackear" o HTML, pois se houver uma atualização ou alguma melhoria posteriormente, todo o meu código ainda funcionará apenas substituindo o framework e não preciso alterar nenhum HTML.
Espero que isto ajude
@Brian, sim!Você pode praticamente controlar todo o comportamento.Considere criar controles personalizados (existem três tipos).Recentemente, dei uma visão geral deles em minha pergunta aqui.
Eu poderia fortemente recomendo dar uma olhada, me ajudou sem fim :)
Eu também estou em minha aventura no ASP.NET e também tive frustrações semelhantes.No entanto, você logo se acostuma.Você só precisa se lembrar, a razão pela qual você não tem a tediosa criação de HTML é porque os controles do ASP.NET fazem tudo para você.
Até certo ponto, você pode controlar/ajustar essas coisas, mesmo que isso signifique herdar o controle e ajustar a saída HTML a partir daí.
Eu tive que fazer isso no passado, onde certos controles não passavam na validação do W3C por padrão, colocando algumas marcações extras aqui e ali, então eu simplesmente substituí e editei conforme necessário (uma correção que durou literalmente alguns minutos).
Eu diria para aprender como funciona o sistema de controles.Então junte alguns você mesmo, isso realmente me ajudou a entender o que está acontecendo nos bastidores, então, se eu tiver algum problema, tenho uma ideia de onde ir.
O HTML é renderizado com esse tipo de IDs porque é a maneira do ASP.NET de evitar colisões de ID.Cada controle de contêiner, como uma página mestra ou um controle de assistente, acrescentará um "ID_" aos IDs de seus filhos.
No caso da sua lista com marcadores, o ListView fornece um bom meio-termo.Você ainda pode vinculá-lo a uma fonte de dados, mas isso oferece um controle muito mais rígido sobre o HTML renderizado.Scott Gu tem uma boa introdução ao ListView aqui:
Se o prefixo do ID adicionado pelo ASP.NET for um problema para você acessá-lo posteriormente usando JS ou algo assim...você tem o lado do servidor da propriedade .ClientID.
Se a sobrecarga for adicionada pelo ASP.NET, você deve considerar o ASP.NET MVC (ainda visualização), onde você tem controle total sobre o HTML emitido.
Estou mudando para o MVC porque também não gosto de todas essas coisas adicionadas ....
Acho que a maioria das respostas aqui adota o ponto de vista do designer.Em um projeto de pequeno a médio porte, pode parecer uma sobrecarga sincronizar código e CSS/HTML e torná-los limpos e compatíveis com os padrões.A maneira de um designer fazer isso é ter controle total sobre o HTML renderizado.Mas há muitas maneiras de ter controle total no ASP.NET.E para mim, ter o HTML necessário no arquivo aspx/ascx é a maneira mais não escalável e suja de fazer isso.Se quiser estilizar controles por meio de CSS, você sempre pode definir uma classe no lado do servidor por meio da propriedade CssClass.Se quiser acessá-los por meio de JS, você pode emitir o JS com os IDs corretos no lado do servidor novamente.A única desvantagem que isso oferece é que um desenvolvedor e um designer precisam trabalhar juntos.De qualquer forma, em qualquer projeto grande, isso é inevitável.Mas as vantagens que o ASP.NET oferece superam em muito essas dificuldades.Ainda assim, se você deseja HTML compatível com os padrões, suporte de skin e outras vantagens para controlar a marcação renderizada, você sempre pode usar controles de terceiros.
Como Dave Ward já mencionou, "é a maneira do ASP.NET evitar colisões de ID".
Um bom exemplo disso é se você estiver tentando colocar um controle dentro de um controle personalizado e, em seguida, usar esse controle personalizado em um repetidor, para que o HTML do controle personalizado seja gerado várias vezes para a página.
Como outros já mencionaram, se você precisar acessar os controles para javascript, use a propriedade ClientScript que lhe dará acesso a um ClientScriptManager e registre seus scripts na página desta forma.Ao escrever seus scripts, certifique-se de usar a propriedade ClientID no controle que você está tentando referenciar, em vez de apenas digitar o ID do controle.
Se você quiser tanto controle sobre o HTML renderizado, dê uma olhada em ASP.NET MVC em vez de.
