Comments on: Separando Javascript do HTML até demais

By: Higor

Higor — Thu, 26 Jun 2008 18:23:05 +0000

Fala Cara,post realmente muito bom.. Olha depois de tantos pontos abordados pelos outros amigos fica dificil deixar de lado os diversos pontos de vista abordados. No primeiro momento em que vi seu post concordei com sua afirmação, considerei exagero separar o código de tal maneira..Eu tinha o hábito de criar um arquivo .js com minhas funções e dessa forma na página eu importava os arquivos com as funções desejadas e pronto.Usando arquivos js o comportamento fica centralizado porem continuamos com as referências nos inputs(eu preferia assim!!) E isso galera..Carlos Parabéns pelo excelente post..

By: Walter Cruz

Walter Cruz — Fri, 03 Aug 2007 02:25:53 +0000

Uma boa razão: HTML 5 não suportará mais eventos diretamente dentro do HTML (http://www.quirksmode.org/blog/archives/2007/04/html_5.html). Tudo bem basta não usar, usar XHTML ou o que existir. Outra coisa que fico pensando: quando o documento tiver o doctype do HTML 5 o browser vai desabilitar o binding de eventos. Acho difícil disso acontecer.

By: anderson

anderson — Tue, 10 Jul 2007 16:03:04 +0000

pois bem, gostei mto do ponto de vista de todos os expositores de ideias.. hehe, virou moda nesta pagina “gostar do ponto de vista” ..( piadinha )..

eh claro, as ideias sao boas, todas, e o mundo ideal é : pegar as partes boas de cada ponto de vista, remodelar, criticar, e formular uma nova ideia “ideal”.. assim evoluiu a humanidade.. e a internet ne..

o meu ponto de vista é: eu colocaria TUDO assim, separado de javascript e do html e do css… sempre. Minha razao? evitar q o designer arrebendo com o codigo. Isso aconteceria mais facilmente ainda se fosse um site tableless…
Ou seja, se vc entrega pro seu designer SÓ os html com só tags htmls ( divs e tabelas ), nenhum acidente nunca acontecerá.. e o trabalho será mto mais facil. Dando inclusive pra trabalhar os 2 em paralelo ( designer e programador )….

caras, eu acho q a minha sugestao nao eh unanime, mas ajuda a clarear alguns “ponto-de-vista” ne

By: Ramon

Ramon — Wed, 20 Jun 2007 00:12:37 +0000

Pode ter certeza, logo logo, vou postar…

Abraços!

By: Carlos Oliveira

Carlos Oliveira — Tue, 19 Jun 2007 15:36:29 +0000

De fato tem razão se analisarmos as duas formas chega a ser uma questão de gosto mesmo.
Pensando agora acho que nunca tive o problema que você apresentou no item 4 porque dificilmente eu faço uma página html sem utilizar partes reutilizáveis, então por exemplo em Rails se houver um botão com estrutura+comportamento iguais em N lugares posso criar um arquivo partial com esse carinha e reutilizá-lo, quando precisar alterar o comportamento não preciso ir no window.onload, posso alterar a chamada no partial e no arquivo .js.
Claro, como você disse vai mudar em dois arquivos, mas novamente o bendito gosto , a divisão fica melhor assim pra mim, pode ser que futuras implementações me façam mudar de idéia.
Mas gostei muito do seu ponto de vista, vou lembrar disso em minhas futuras implementações com certeza, não havia lembrado desses pontos e são muito importantes para quem ler este post decidir por uma forma de implementar.
Já adicionei seu link rss no meu google reader , fico no aguardo do post hein!

Abraços!

By: Ramon

Ramon — Tue, 19 Jun 2007 13:04:16 +0000

Bom ponto de vista e com isso não tenho mais argumentos, pois já virou uma questão de gosto e gosto é igual ao c… cada um tem o seu e o defende como pode, porém em relação ao window.onload o código não cresce vertiginosamente por alguns motivos:

1. A função window.onload, provavelmente, irá fazer apenas as chamadas para as funções.

2. Você só vai fazer a chamada da função no window.onload, quando essas funções forem necessárias serem carregadas lá!

3.Para cada chamada de função vai ter apenas uma linha de código, vc pode fazer a chamada da função sem a necessidade de uma variável.
Ex: document.getElementById(“meubotao”).onclick = minhafuncao();

4. Para mim esse motivo é o mais importante, quando vc for fazer a manutenção do código (comportamento), vc não precisa ir no html(estrutura), e com isso vc ganha bastante tempo, pois não precisa fazer a mudança de dois arquivos para uma simples manutenção.

Conclusão:
Eu sou extremamente a favor de chamar a função pelo javascript e vc nem tanto, não creio que há um certo ou errado nessa história, mas gostei dessa “discussão”, porque nunca tinha parado para analisar essas diferenças e isso só amadureceu a minha opinião.

ps: Depois dessa “discussão” toda vou roubar o tema e abordar lá no meu blog!

Abraços.

By: Carlos Oliveira

Carlos Oliveira — Mon, 18 Jun 2007 22:52:51 +0000

Oi Ramon, de forma alguma foi arrogante, pelo contrário, adoro quando alguém comenta porque me faz refletir se o que eu escrevi está mesmo certo, afinal não sou dono da verdade e estou aberto a mudar meu ponto de vista, refatorá-lo por assim dizer =D.

Então vamos lá, realmente você está certo em afirmar que ao colocar a chamada no window.onload, para “linkar” os objetos com os eventos, vai ajudar no momento em que for necessário uma mudança de evento para N objetos que tem o mesmo comportamento.

Gostei do seu ponto de vista, vou tentar refatorar o meu então, vamos ver se você concorda comigo.

No caso acima, você está certíssimo, mas e nos casos em que o evento+objeto existem uma única vez em toda a aplicação? Isso é comum, sendo assim todo evento que estiver ligado a um objeto você tem que colocar no window.onload que vai crescer vertiginosamente a medida que sua aplicação cresce, se não tomar cuidado vai perder o controle da manutenção facilmente, pra não falar que se este window.onload estiver grandíssimo pode sobrecarregar a engine de javascript, tornando o browser lento, claro que isso só ocorreria em casos extremos, mas como estamos falando de tirar todo o comportamento da parte estrutural, dependendo da quantidade de objetos e eventos isso pode ocorrer.

Então novamente, concordo com você, mas somente para os casos em que o mesmo evento é usado N vezes, já para os casos de eventos únicos, para o bem da minha sanidade prefiro continuar usando o onclick inline mesmo

Aliás para esses casos em que uma objeto+evento é repetido várias vezes, como o seu caso de um botão para validar data, ao invés de criar o mesmo botão manualmente, prefiro deixar ao cuidados de um framework ou criar um um pequeno componente para esta funcionalidade que vai ser reutilizado para renderizar da mesma forma em N lugares. Sendo assim poderia manter o onclick inline, e quando quisesse alterar, bastaria alterar nesse único componente.

Espero não ter sido confuso.
Abraços

By: Ramon

Ramon — Mon, 18 Jun 2007 19:25:52 +0000

Olá,
leio algumas matérias suas e gosto do seu ponto de vista, porém hoje no entanto, não concordo com a sua opinião. Vc está certíssimo em afirmar que vai gerar mais linhas de códigos, porém se parar pra contar não são tantas linhas a mais, são duas ou três linhas a mais, que dependendo do tamanho do seu arquivo vai te ajudar bastante para fazer uma futura manutenção. Com certeza, para quem não é acostumado com esse método pensa que é um desperdício de tempo e que não vai afetar em nada colocando no botão já que é aceito e é muito mais fácil (eu tb pensava assim), mas fui acostumando e percebi que chamando pelo javascript evitava uma dor de cabeça imensa. Vou te dar um exemplo:

Tenho uma função de validação de data, que é usada em um monte de botões do meu site (a efeito de exemplo 20 botões) e fui atribuindo essa função em cada botão via html, pois bem, em um determinado dia meu chefe fala que vai haver uma mudança nas funções desses botões (agora sim, vc vai ver o efeito devastador disso), então o que você faz? Tem que ir no html, procurar os botões que irão sofrer a alteração e mudar a função a ser chamada, ou seja, uma mudança apenas de comportamento vc tem que ir na estrutura para fazer tal mudança (o que é algo sem sentido). Mas da outra forma esse problema é facilmente resolvido, vc não precisa ir na parte estrutural do site para fazer a mudança. Vc sabe que fez a atribuições dos elementos no window.onload, então vc vai direto lá e faz a alteração da chamada da função . Dessa forma, não gastou tempo procurando pelos botões e o mais importante não precisou ir na parte estrutural para fazer uma alteração comportamental.

Com isso, quero dizer que de fato para começar a fazer o código é mais demorado (só o início, pq depois toda a estrutura está feita e é só atribuir o evento à função), mas para a manutenabilidade é muitooo mais fácil.

fuiii…
ps:Espero não ter sido arrogante no meu ponto de vista.