Arquivo da tag: browser

Deixando o componente ASP:MENU compatível com qualquer browser

Fonte: Mauricio Junior/IMasters

Olá, pessoal! Nos dias de hoje estamos, praticamente, na era da web 3.0, onde tudo funciona por e através do browser. Para quem desenvolve utilizando os componentes nativos da Microsoft e do Visual Studio 2010, sempre houve problemas de compatibilidade em alguns casos. E o mais difícil deles é o do <asp:menu>, aquele que aparece menu >> sub menu >> sub sub menu e assim por diante…

O objetivo desde artigo é mostrar como deixar o componente asp:menu do seu site, ou sistema, compatível com qualquer browser.

O interessante de usar o <asp:menu> é a integração simples e fácil que ele possui com o banco de dados. Dessa forma, o menu é trazido do banco de dados e montado na tela rapidamente.

A maioria dos aplicativos hoje não possui compatibilidade entre os browsers. Se o usuário estiver utilizando o Chrome, o Firefox ou o Safari, o menu não abre e quando se clica nele, ele some. Para deixar o menu compatível com todos os sites foi preciso seguir alguns passos importantes. Vamos lá!

Primeiro passo:

Gerar uma pasta chamada App_Browsers dentro do Visual Studio 2010.

Ele vai criar uma pasta exclusiva para browser, então cliquei com o botão direito em cima da pasta App_Browsers para criar um novo item.

O próximo passo é escolher o tipo do arquivo. Geralmente, ele tem a extensão “.browser”.

Coloque o nome do arquivo “Safari.browser” e clique no botão Add. Automaticamente aparecerá o arquivo com algumas tags específicas. Apague todas e coloque o código abaixo.

<browsers>

    <browser refID="Safari1Plus">

        <controlAdapters>

          <adapter controlType="System.Web.UI.WebControls.Menu" adapterType="" />

        </controlAdapters>

    </browser>

</browsers>

Pronto, agora o seu componente está funcional em qualquer browser, mesmo carregado dinamicamente pelo banco de dados, ou qualquer outro tipo de dado.

Por que Bons Programadores são Preguiçosos e Idiotas

Eu percebi, paradoxalmente o suficiente, que bons programadores precisam ser tanto preguiçosos quanto idiotas.

Preguiçosos, porque apenas programadores preguiçosos irão querer escrever os tipos de ferramentas que podem substituí-los no final. Preguiçosos, porque somente um programador preguiçoso vai evitar escrever código monótono e repetitivo – assim evitando redundância, o inimigo da mantenabilidade e flexibilidade de software. No mais, as ferramentas e processos que vêm disso, disparados pela preguiça, irão aumentar a produção.

Claro, essa é apenas meia verdade. para um programador preguiço para ser um bom programador, ele (ou ela) também devem ser extremamente não-preguiçosos quando é hora de aprender como ser preguiçoso, ou seja, quais ferramentas de software tornam seu trabalho mais fácil, quais técnicas evitam redundância, e como ele pode fazer seu trabalho ter mais mantenabilidade e ser facilmente refatorado.

Segundo (e vou elaborar mais sobre isso porque acho que esse conceito é menos conhecido que o primeiro) um bom programador precisar ser idiota. Por que? Porque se ele é esperto, e ele sabe que é esperto, ele vai:

1. parar de aprender

2. parar de ser crítico a respeito do seu trabalho

Ponto a) tornará mais difícil para ele tentar encontrar novas técnicas para permiti-lo trabalhar mais rápido. Ponto b) tornará difícil a ele debugar seu próprio trabalho, e refatorá-lo. Na batalha interminável entre um programador e o compilador, é melhor para o programador desistir rápido e admitir que é sempre ele e nunca o compilador o culpado (a menos que seja codificação de caracteres, que é a parte que até mesmo compiladores erram.)

Mas existe um ponto mais crucial de porque bons programadores precisam ser idiotas. Isso porque para ele encontrar as melhores soluções a um problema, precisa manter uma mente aberta e pensar fora da caixa (ou melhor, conhecer seu formato real). De certa forma, isso leva à mentalidade de uma criança; incrivelmente criativa porque ele nunca ouviu “não” como resposta.

O direto oposto não seria muito construtivo; ser conhecedor dos parâmetros à mão e aceitá-los. Porque quem sabe quantos limites você acha que existem, na real? Quanto menos você souber, mais radical serão suas escolhas; melhores as ferramentas que você desenvolve, e melhor o produto que você desenvolve com elas.

Eu conheço do meu trabalho um bom programador, quando confrontado com um problemas da gerência, adotará essa mentalidade de ser idiota; ele começará a perguntar as questões mais simples e infantis. Porque ele não aceita os parâmetros sugeridos a ele que alguém acha que definem o problema. Aqui está uma típica conversa da terra perdida do desenvolvimento web:

  • “Desde ontem, nosso cliente não consegue ver o logotipo no web site.”
  • “Ele reiniciou o browser?”
  • “Sim.”
  • “Ele reiniciou o computador?”
  • “Sim.”
  • “Ele limpou seu cache?”
  • “Sim.”
  • “Ele roda Internet Explorer 6?”
  • “Sim.”
  • “Ele tem certeza que não consegue ver?”
  • “Sim.”
  • “Ele olhou para o web site na tela?”
  • “O que?”
  • “Bem, ele pode ter impresso.”
  • “Não, ele estava olhando para a tela.”
  • “Ele também não viu outras imagens além do logo?”
  • “O que? Bem, vou perguntar a ele.”

Apenas para a argumentação (isso foi inteiramente hipotético) vamos dizer que o cliente de fato desligou as imagens do seu browser. Ou seu filho desligou. Seja qual for o caso, essa resposta não seria encontrada se você trabalhasse com um programador em modo1 “esperto”. Nenhuma das perguntas perguntadas pelo programador requerem qualquer habilidade de programação. Não, simplesmente porque o problema é tão estúpido, apenas estupidez pode resolvê-la.

Alguns anos atrás, eu tive uma longa discussão no telefone sobre o web site ter quebrado desde minha última atualização … acabou que a pessoa desabilitou os stylesheets em seu browser. Na época eu teria suspeitado de tudo menos numa solução tão simples e fiquei escutando meia hora de reclamações sobre padrões de qualidade, etc. No final, a premissa que minha atualização foi culpada era apenas isso … uma premissa. Melhor você ouvir apenas os fatos se começar a debugar, e nunca no que as pessoas acham que pode ser a razão.

De forma similar, quando um dos meus colegas programadores me pergunta: “Por que isso não está funcionando?” na maioria das vezes é porque ele está trabalhando no arquivo errado (ex. ele linkou na biblioteca 1, mas alterou na biblioteca 2, e sua revisão não aparece ou simplesmente não linkou na biblioteca.) Quando você pede ajuda a seu colega, particularmente sobre programação, você espera que ele saiba menos sobre o projeto … então ele faz perguntas estúpidas que você evitou perguntar a si mesmo de forma sub-consciente, porque você achava que sabia as respostas, quando de fato não sabia.

Existe outro lado nisso. A pessoa idiota-demais vai somente sair correndo e, sem pensar duas vezes, fazer algo errado. A pessoa esperta-demais vai se sentar e planejar algo certo, sem tomar nenhuma ação. Um programador pragmático está mais ou menos no meio; ele sabe que tomar a decisão errada 1 vez em 10 não machuca os objetivos tão mal quanto 5 decisões certas de 10, e não decidir nada nas outras 5 vezes.

É como a história da centopeia. A centopeia era muito boa em andar com suas cem pernas. Ela nunca pensou em como conseguia andar. Até que um dia, quando um inseto preto grande perguntou a ela “Como você consegue andar com tantos pés? Não acha difícil coordenar seu ritmo?” O inseto grande preto já tinha ido embora, enquanto a centopeia ainda estava sentada, ponderando como ela conseguia andar, se perguntando e (pela primeira vez na vida) até mesmo se preocupando um pouco. Desse dia em diante, a centopeia não conseguia andar mais.

Então, melhor não pensar demais se quiser conquistar alguma coisa. E, claro, essa é somente meia verdade também…

Fonte: blogoscopted
Traduzido por: akitaonrails.com