[Cascavel-pm] XML no Perl

[Nilson Santos Figueiredo Junior]

On 4/23/07, Luciano Giordani Bassani <lgbassani em terra.com.br> wrote:
> Posso citar várias razões para se usar iframes. A mais importante para a
> adoção no grupo de portais que eu citei é a de cache. Graças ao uso
> maciço de iframes, conseguimos atender a uma grande demanda de acessos,
> sem grandes investimentos em hardware. Por exemplo, o menu principal só
> é carregado 1 vez.

É exatamente a falta de performance proveniente dos iframes um dos
problemas principais dos iframes. Você pode até ter economizado um
pouco de *banda* utilizando iframes vs. soluções convencionais. Mas se
isso fosse realmente importante assim, você poderia ter soluções que
economizariam banda *e* processamento, sem a utilização de práticas
ruins de desenvolvimento.

O seu menu principal só é carregado uma vez, mas ele corresponde a
alguns poucos bytes e, de acordo com a configuração do browser dos
usuários e/ou com a utilização incorreta dos headers de controle de
cache, pra cada request efetivo, seu servidor na verdade tem de servir
dois requests. É muito mais eficiente em questão de processamento você
servir tudo como um request só, pois significaria somente mais alguns
bytes a serem gerados. Se realmente quisesse economizar alguns míseros
bytes a mais de banda, poderia ter encapsulado todo o menu em código
JavaScript que seria feito cache e sua página principal apenas faria a
chamada (ou nem isso, seria carregado automaticamente através de
eventos).

> Outra vantagem, é descentralização. Graças ao uso do iframes, podemos
> ter jornalistas escrevendo matérias e jogando seu texto escrito em algum
> Word da vida direto no portal, uma webdesigner que dá conta sozinha do
> visual do site, etc.

Juro que tentei entender o que isso tem a ver com iframes mas não
consegui. Porque iframes permitem que jornalistas escrevam matérias?
Até onde eu sei, qualquer campo de texto serve pras pessoas
escreverem. De fato, o iframe nem é um campo de texto, o que torna
essa afirmação ainda mais confusa.

Se você está se referindo à aqueles campos de edição Rich Text, bem,
isso é apenas uma restrição tecnológica e, assim como no caso da
utilização de iframes pra esconder selects no IE6, é algo
perfeitamente válido. Mas ainda estou confuso se você se referia a
isso mesmo.

> Mais uma vantagem: facilidade na manutenção. Graças aos iframes, apenas
> 1 pessoa consegue programar, manter, administrar o servidor co-location
> do referido cliente, e ainda por cima se envolver em outros projetos...

Gostaria de entender qual a facilidade de iframes vs div dinâmicas
carregadas via requests assíncronos. O segundo caso, normalmente, é
mais eficiente em recursos pro servidor e provê uma experiência melhor
pro usuário final. E é fácil, quando você utiliza qualquer uma das
bibliotecas disponíveis para auxílio. Além dos aspectos de
acessibilidade e usabilidade, se é que as pessoas se importam com isso
por aqui...

> Bom, se tu quiser um exemplo do que iframes pode fazer por vc, dê uma
> olhada em um projeto de nossa empresa:  http://www.eventor.com.br (é uma
> aplicação web de verdade! ;-) )

Vou mandar as impressões que tive do site diretamente para você.

-Nilson Santos F. Jr.