Tableless, a saída leve e sem sobrecarga de servidores?

[Omykron]

para quem não sabe, Tableless eh um método de desing semelhante ao <table>, só q usa o parametro <div> para separar a informação.

para se ter uma idéia, a informação contida em uma table , só eh completamente carregada caso as tags </td>, </tr> ou </table> sejam lidas pelo Browser. caso este nao as leia, a informação q estava na célula x q naum tem marcação de fim, se perde....
caso tipico ocorrido no ataque de 11 de setembro, que fizeram q varios sites hospedados em maquinas no WTC entrassem OVERFLOW e causando seguidos CRASH nos servidores....

para quem nunca viu um site TABLELESS, aquitem uma boa quantidade de material para ver.... e usa alguns grandes sites de exemplo... como o da VIVO, q eles tem uma versao interna q usa Tableless e a original (tableless carrega até 3x mais rapido)

 

[Beren]

Interessante.. pena q eu não consiga entender nada dessa coisa de DHTML, XML, e blah blah blah =( alguma sugestão de onde consigo infos sobre isso??


bom.. dei uma olhada e só agora caiu a ficha de o que é tableless

bom achei interessante a idéia mas ainda n entendi como utilizar isso nas minas páginas.. achei aliás muuito interessante =) pq ateh antes de eu saber sobre <table> eu tentava fazer algo assim hehehe... só não entendi cmom que eu vou organizar a página para colocar o conteúdo lado a lado =/

 

[Omykron]

no forum da Blaz tem mais info

forum.blaz.com.br

 

[Cildraemoth]

Os comandos <table> são inconvenientes para O CLIENTE, pois o navegador deste tem que ler a tabela inteira para só então começar a montá-la. (Embora haja já técnicas que eliminam essa restrição.)

Mas não consegui entender qual a diferença para um servidor enviar uma série de <table><tr><td>... ou um monte de <div>... São só dados, o servidor nem sabe o que tem na página...

 

[Omykron]

a diferença q a tag <div> naum precisa obrigatóriamente de um </div> para o browser desenhar ela.... e o principal, ela mantem a informação acima de tudo.

 

[Beren]

eu pensei q usando simplesmente um <div align="center">A</div> <div align="left">C</div> <div align="right">B</div>
funcionaria... mas não adiantou nada =( n entendi 100% ainda desta coisa mas achei bem interessante =)

 

[Cildraemoth]

a diferença q a tag <div> naum precisa obrigatóriamente de um </div> para o browser desenhar ela.... e o principal, ela mantem a informação acima de tudo.

Perfeitamente. E onde entram os servidores nessa história, já que isso só torna as coisas melhores para os clientes?

 

[Omykron]

a diferença q a tag <div> naum precisa obrigatóriamente de um </div> para o browser desenhar ela.... e o principal, ela mantem a informação acima de tudo.

Perfeitamente. E onde entram os servidores nessa história, já que isso só torna as coisas melhores para os clientes?

quando um cliente faz um request de um site para o servidor, esse vai devolver a linha de comando
mas o BROWSER só para de falar com o servidor (enviar requests) quando a tag <table> for concluida
caso naum conclua
o desenho dela fica quebrado, e perde-se informação (vital para a web)
ai o usuario faz outro request, até q a tabela saia completa, o q vai sobrecarregar o servidor
foi o q aconteceu no dia 11-09-2001. como tinham partes de sites hospedadas em servers dentro do WTC, como o da Yahoo!, o servidor chegou a um limite e caiu, gerando o caos de informação q rolou

 

[Gloin moicano]

qual a diferença? enquanto o navegador não receber um "fim de arquivo" ele vai continuar recebendo pacotes do servidor, independete de que tag vc tá usando

 

[Omykron]

qual a diferença? enquanto o navegador não receber um "fim de arquivo" ele vai continuar recebendo pacotes do servidor, independete de que tag vc tá usando

naum com a tag <div> ja que ela apenas marca posicionamento inicial.... naum ficando presos a <td> <tr> como a tabela fica, fazendo o codigo ficar mais leve, e fazendo com q ele fica mais rapido na hora do browser construir ele para o usuário

 

[Gloin moicano]

Perfeitamente. E onde entram os servidores nessa história, já que isso só torna as coisas melhores para os clientes?

 

[Beren]

meu professor de C no colégio deu umas dica de Tableless.. e agora entendi.. vc usa coordenadas para localizar a sua caixa e tal... ou imagm.. ou o que seja...

<div style="position: absolute; left: 130;top:15"> eh +/ n isso neh? agora sim hehehe (espero! )

 

[Gloin moicano]

isso é legal qnd vc quer criar camadas em cima do texto, daí vc pode vc elas aparecerem, desaparecerem, andar pela tela e mais um monte de frescurinha massa, criar menus...

 

[Cildraemoth]

Não convenceu. O processo funciona assim: O browser do usuário faz uma conexão ao servidor, e pede uma determinada página (digamos index.html). O servidor começa a mandar.

Se terminar, ótimo. Se não terminar, o browser mostra o que for possível mostrar (possivelmente nada) e pronto. Nenhum navegador dos que eu conheça tenta automaticamente quando dá erro. Só se o usuário apertar o botão "Reload".

E, caso o navegador tentasse novamente até conseguir o carregamento até o fim, o fato de usar <table> ou não não influencia: mesmo sem <table>, a página seria vista como incompleta. E ele pediria de novo.

Agora vamos supor que o servidor caia no meio da transferência de uma página. O máximo que vai acontecer é que vai ser enviado um novo pedido, automaticamente ou não. Mas, como o servidor está offline, esse pedido não será entregue. O usuário receberá uma mensagem de "timeout" após um tempo determinado. É mais fácil sobrecarregar uma rede com o comando "ping" do que com isso...

 

[Omykron]

a diferença ex, eh q tableless vc naum segura o client no servidor, até o fim do </table> ou de algum </td> </tr> q a tabela faz, vc simplesmente diz aonde fica a posição e pronto, ele ja desenha, enquanto tabela, ele vai montando aos poucos, esperando TODOS elementos da tabela, até dar timeout...
ou seja
vc ta no servidor, e vc soh para de enviar requests para ele quando a tabela chega, enquanto no tableless ele usa isso para pedir a informação (o principal)

 

[Gloin moicano]

vc fica pendurado no servidor ate a acabar a sessão,
vc não fica falando pro servidor:
- agora eu quero o conteúdo da tabela
- e agora quero o </table>
- ah, não esquece de mandar o </td> antes, blz?
vc simplismente recebe um stream que o cliente, no caso, o navegador, monta uma página html
o único ganho em toda essa sua explicação é que a página é montada mais rápida

 

[Cildraemoth]

A explicação do gloin está perfeita. A visualização é mais rápida para o cliente, mas para o servidor é irrelevante a diferença. O servidor nem sabe se está mandando <table> ou <div>: para ele são só bytes. E se a página vier incompleta, não há tag que consiga prever o que viria depois, então tem-se que tentar de novo, mesmo que parte já tenha sido mostrada.

 

[Omykron]

segundo o colunista da blaz tableless eh isso:

Um dos problemas do uso de tabelas é a "blocagem" do acesso ao documento: O
browser espera o </table> para renderizar o código. Se coloca todo o
conteúdo do HTML dentro de uma <table>, com excessão do Mozilla ou uso de
um certo atributo do CSS, o browser só renderiza quando todo o conteúdo do
<table> estiver no cache.

Num site tableless não apresenta este problema, o documento é exibido a
medida que chega.

Fez um ano os atentados de 11 de Setembro, que além de derrubarem as torres
e o pentágono, derrubou os sites dos portais por causa da sobrecarga de
acessos, obrigando a estes colocarem às pressas versões "lights" de front
pages.

Coisa que seria desnecessária, se houvesse prioridade da informação sobre a
formatação. Com tabelas, fica priorizado a formatação. Com tableless,
prioriza a informação.

Funciona assim em tableless: Você requisita a página, e os primeiros bytes
que chegam, é a informação. Se sobrar banda, a informação termina de
chegar. Se depois ainda tiver banda disponível, vem o CSS para arrematar.

Funciona assim em table based: Você requista a página, e os primeiros bytes
é um desfiles de <table>, <tr> e <td>s. Pode ser um defile longo, por causa
de aninhamento de tabelas. Depois a informação. Aí, os navegadores tem que
esperar os </td>, </tr> e </table>s para finalmente renderizar a informação.

No caso do 11/9, o pessoal acessava, mas por causa da sobrecarga, nem
sempre se conseguia chegar ao usuário os </table> para exibir a informação.
(e nesse meio tempo, o usuário dava reload da página, para ver se
carregava, o que sobrecarregava novamente o servidor, por requisitar
novamente os <table>, <tr>, <td>...)

Tableless em tempos de guerra é assim: Chega a informação primeiro. Se o
servidor não servir a parte final da requisição - a formatação - que se
exploda, a informação foi enviada.

se quiser ler mais, só da um crique-crique

 

[Gloin moicano]

acho que é o seguinte: qnd se usa o div para posicionamento, o navegador monta mais rápido pq não precisa de toda a estrutura da tabela pra desenhar a página. como se usa apenas a tag div o código fica mais enxuto e a página carrega mais rápido por dois motivos: primeiro pq o código está alguns bytes menor e segundo pq o div dá direto o local de desenhar o conteúdo, o navegador só precisa de um <div> e um </div>. ou seja, vc não precisa ficar apertando várias vezes o "recarregar" achando que tá baixando nada, e assim não precisa fazer um monte de get ou request para o servidor, não precisando retransmitir todo o conteúdo de novo e desafogando ele um pouco

deve ser isso que vc tá querendo dizer com "a saída leve e sem sobrecarga de servidor"

agora esse lance de sobrar banda e mandar o resto, sei não...

 

[Cildraemoth]

O fato da sobrecarga no dia 11/09 provavelmente se deve ao fato de que todo mundo estava tentando acessar sites como a CNN, ABC, BBC em busca de notícias. Isso aumentou muito a quantidade de acessos, causando problemas.

O fato de o usuário apertar reload não tem nada de diferente de alguém tentando ver a página. Se o servidor agüenta 1.000 de visitores baixando uma página simultaneamente, vai agüentar os mesmos 1.000 apertando reload. Só vai dar problema se mais gente tentar ver ao mesmo tempo, mas isso é porque a informação é muito desejada, não tem nada a ver com a tag usada.

A única vantagem seria que, se a página for interrompida no meio, você conseguirá ler metade dela. Mas terá que carregar a página de novo para ler o resto. A não ser que a metade da página seja já suficiente...