| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Podes ver aqui.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| |
|
| | Evita.
Motivo:
1. Não resolve nada que não seja facilmente resolvido de outra forma.
2. Complica-te a vida imenso.
3. É pesado como tudo.
|
| |
| |
| | Não sejas tanso... por exemplo, o XSLT foi-me bastante útil num projecto em que trabalhei pois permitiu transformar informação vinda do Business Connector do SAP em formato XML para exibir a conta-corrente de um cliente no website, todo bonitinho, integrado com o layout do site e com as continhas todas feitas.
Pois, podia ter feito N linhas de código para processar essa informação no XML, mas esta solução é muito mais elegante. KISS e nada de reinventar a roda.
---
Este espaço pode ser seu! |
| |
| | permitiu transformar informação vinda do Business Connector do SAP em formato XML
ena, tantas buzzwords numa só frase
3 pontos para o Cliff
Pois, podia ter feito N linhas de código para processar essa informação no XML, mas esta solução é muito mais elegante. KISS e nada de reinventar a roda.
N linhas de código... hum...
e com XSLT presumo que tenhas feito numa só linha?
XSLT tem a seu lugar, talvez na conversão de xml para algo diferente, mas não em websites onde normalmente o esquema de templating (onde a maioria das pessoas gosta de meter o XSLT) exige alguma lógica...
Claro que o mundo é gerido pelas buzzwords e pelo transe das massas. Nem vou discutir isto. Usem XSLT em tudo.
|
| |
| | Na sejas parvo pq isso comigo não pega. Começas logo por falar em buzzwords por isso suponho que já tenhas ouvido falar daquilo mas não faças puto de ideia do que é. não faz mal, já é hábito.
O XSLT permitiu-me utilizar um template lá no meio, meter umas quantas tags de xslt, meter isso e o xml pelo jaxp e fiquei despachado com informação on-the-fly sobre a conta corrente de um cliente.
Mas para que é que estou a discutir palácios com um burro?!
---
Este espaço pode ser seu! |
| |
| | Deixa lá, aquelas afirmações parecem de quem ainda não teve de receber informações de um web service ou algo semelhante que devolva os resultados em xml, senão nao estava a dizer tais coisas, quer se goste do XSLT quer não se goste é muito melhor e mais rápido utilizar um XSLT para transformar resultados do que estar a pegar nos resultados obtidos em XML importar a informação para uma estrutur de dados e depois mostrar essa informação.
------------------------------------------------------------
Todas as coisas mudam, e nós mudamos com elas. |
| |
| | Mas vocês já ouviram falar em perl??
|
| |
| | O PERL neste caso não pôde ser utilizado, nem fazia qualquer sentido.
---
Este espaço pode ser seu! |
| |
| | Deixa lá, aquelas afirmações parecem de quem ainda não teve de receber informações de um web service ou algo semelhante que devolva os resultados em xml
Sou gajo para já ter feito isso, sim.
senão nao estava a dizer tais coisas
por isso mesmo estou a dizer estas coisas.
quer se goste do XSLT quer não se goste é muito melhor e mais rápido utilizar um XSLT para transformar resultados do que estar a pegar nos resultados obtidos em XML importar a informação para uma estrutur de dados e depois mostrar essa informação.
Presumo que não saibas que o modelo DOM não é a unica maneira de utilizar uma arvore de XML.
|
| |
| | Na sejas parvo pq isso comigo não pega.
Cliff: Testosterona +1
Começas logo por falar em buzzwords por isso suponho que já tenhas ouvido falar daquilo mas não faças puto de ideia do que é.
Sou capaz de ter uma ideia, sim.
O XSLT permitiu-me utilizar um template lá no meio, meter umas quantas tags de xslt, meter isso e o xml pelo jaxp e fiquei despachado com informação on-the-fly sobre a conta corrente de um cliente.
espectáculo.
Mas para que é que estou a discutir palácios com um burro?!
Sim, a discussão não era sobre um programa específico que aceita templates XSLT, mas sim sobre a tecnologia em si. Mas se achas que disparar tanta buzzword fora de contexto te faz parecer inteligente, força.
Desculpe não ser tão buzzword-enable como sua majestade.
|
| |
| | A tecnologia XSLT, como disse no 1o post que fiz ao qual respondeste bem à tua maneira, foi bastante útil para resolver um problema de maneira rápida e eficaz.
O resto não comento porque não me mereces a mínima consideração... pateta.
---
Este espaço pode ser seu! |
| |
| | O resto não comento porque não me mereces a mínima consideração... pateta.
Já não vou dormir hoje. Queria que fosses meu amigo.
|
| |
| | | ena, tantas buzzwords numa só frase Sabes o que e' o Business Connector da SAP ? Nao ? Entao talvez nao devesses comentar porque de facto usar XSLT e' a forma mais comum de converter XML atirado de middleware (outra buzword) para outros formatos... podia te dar mais umas buzwords como exemplos, mas e' melhor nao.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Sabes o que e' o Business Connector da SAP ? Nao ? Entao talvez nao devesses comentar porque de facto usar XSLT e' a forma mais comum de converter XML atirado de middleware (outra buzword) para outros formatos...
forma mais comum != forma mais acertada
PS: tava a ver que não entravas numa discussão de buzzwords vs tecnologia a sério
|
| |
| | | forma mais comum != forma mais acertada Ok, muito bem -- entao qual e' para ti a forma mais "acertada" ? E como e' que defines "acertada" ? E' que o "acertado" para mim se calhar para mim nao e'...
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Ok, muito bem -- entao qual e' para ti a forma mais "acertada" ? E como e' que defines "acertada" ? E' que o "acertado" para mim se calhar para mim nao e'...
Por "forma acertada" quero dizer a utilização dos recursos mais adequados para determinada situação (em vez de seguir as modas).
Não existe espaço para a subjectividade quando se trata de performance/custos.
|
| |
|
| Mundo! (Pontos:3, Esclarecedor) |
| | | Para criar sites não creio que o XSLT seja a melhor solução. Eu tou num projecto que tem XML a dar com um pau e temos N formas de criar páginas apartir do XML, mais rápidas e eficazes. Seja como for o XSLT é uma ferramenta excelente quando bem utilizado, principalmente no mundo dos webservices. Recebes uma mensagem em XML, e alteras essa mensagem com um xslt naturalmente. Mas como alguém já disse, o XSLT é lento, o XPath é lento, e devem ser bem ponderados. Têm o seu lugar, mas também não os queiras por em todo o lado (como por exemplo sites).
_____________________
Pedro Santos :: psantos.net :: blog |
| |
| | Por acaso trabalho no mesmo lugar que tu, mas não recomendo! (basicamente porque o Opera ainda não suporta...) Mas também não sou eu quem manda... :-)
«You cannot steal a gift, which is what code released under the BSD license is.» |
| |
| |
| | Já estamos a fazer a transformação no servidor porque ficava muito lenta no browser, portanto ja funciona no opera :-)
----------------------------
if it bleeds, we can kill it |
| |
| | Já estamos a fazer a transformação no servidor porque ficava muito lenta no browser, portanto ja funciona no opera :-)
Hum... e quantos pedidos aguenta isso?
Não se agarrem às caches que não é preciso. :)
|
| |
| Nah.. (Pontos:3, Interessante) |
| | Embora eu veja principalmente como sistema de templates para páginas estáticas (pelo menos, até o suporte nos browsers ser COMPLETO), nem isso me agrada muito.
Acontece que a sintaxe, embora muito poderosa, é algo ilegivel. Não quero dizer que seja complicada por aí além, mas não acho "straightfoward" o suficiente para ver o XSLT como vantagem a outro sistema de templates qualquer. Claro que o objectivo final não são as páginas pré-geradas, mas a sintaxe não me agrada mesmo.
|
| |
| |
| | Embora eu veja principalmente como sistema de templates para páginas estáticas (pelo menos, até o suporte nos browsers ser COMPLETO), nem isso me agrada muito.
Usar isso nos browsers não me parece nada simpático. Já viste um browser a processar algo mais complexo em XSLT? É puro desperdício de ciclos de CPU.
Acontece que a sintaxe, embora muito poderosa, é algo ilegivel. Não quero dizer que seja complicada por aí além, mas não acho "straightfoward" o suficiente para ver o XSLT como vantagem a outro sistema de templates qualquer. Claro que o objectivo final não são as páginas pré-geradas, mas a sintaxe não me agrada mesmo.
Nessa estamos juntos, excepto num ponto: "...a sintaxe, embora muito poderosa...". Não é mais poderosa que um parser qualquer de XML numa linguagem qualquer deste século (ou do século passado).
|
| |
| | Usar isso nos browsers não me parece nada simpático. Já viste um browser a processar algo mais complexo em XSLT? É puro desperdício de ciclos de CPU.
Antes do lado do cliente, que os tem para dar e vender, do que do lado do servidor :)
De qualquer modo, o que eu queria dizer era que me parece que a ideia original do XSLT seria mesmo usá-lo nos browsers, fornecendo os dados em XML e a stylesheet à parte. É que tirando esta já mais interessante potencialidade (basicamente, templates client-side), não vejo muito interesse que sobre no XSLT tal como ele é.
|
| |
| | Usar isso nos browsers não me parece nada simpático. Já viste um browser a processar algo mais complexo em XSLT? É puro desperdício de ciclos de CPU.
Antes do lado do cliente, que os tem para dar e vender, do que do lado do servidor :)
Cometeste dois erros nessa resposta:
1. Nem todos os utilizadores tem máquinas potentes e/ou pachorra para gramar com sites lentos a render
2. Melhor que pesar do lado do cliente é não pesar em lado nenhum.
De qualquer modo, o que eu queria dizer era que me parece que a ideia original do XSLT seria mesmo usá-lo nos browsers
Não querendo entrar em erro, penso que a ideia não era especificamente essa, mas sim ser uma linguagem fácil para transformar XML.
fornecendo os dados em XML e a stylesheet à parte. É que tirando esta já mais interessante potencialidade (basicamente, templates client-side), não vejo muito interesse que sobre no XSLT tal como ele é.
Há muitas outras coisas interessantes para fazer com XSLT. Não são é coisas tão óbvias. Docbook é um bom exemplo.
|
| |
| | | Uso essencialmente para transformações de XML, filtragem e formatação de dados contidos no XML, e também para fazer 'reports'. É uma analogia grosseira mas imagina o XML como uma 'data source', e o XSL como um 'report generator'. Quanto à lentidão, varia muito com o processador de XSL utilizado. Mas para situações onde a performance é essencial, e caso utilizes templates recursivas, não aconselharia.
Plexar. |
| |
| | | ... fizemos o jogos.oninet.pt em XML/XSL (e tb o downloads.oninet.pt q parece estar offline). O endereco sem index.xml usa um processador XSL para debitar cá para fora HTML. Nota-se a diferenca de speed em relacao ao link anterior. Nao gostamos. Dá mais trabalho e tem mais desvantagens (ie totalmente ilegivel e ingerivel) do que vantagens. O BlogDot já foi feito com XML+CSS que é um combo *muito* melhor. O site da Personalis tb está a ser feito com o mesmo combo.... Cumprimentos Mario Valente
|
| |
| |
| | E mais...
jogos.oninet.pt em Firefox:
"Error loading stylesheet: An XSLT stylesheet does not have an XML mimetype:
http://jogos.oninet.pt/jogos/indexV2.xsl?"
jogos.oninet.pt em IE6:
Tudo ok.
Mário Gamito
www.startux.org |
| |
| | Deve estar optimizado para msxsl :->
Mas agora fora de brincadeiras, o problema do xsl ainda é este mesmo, muitas das coisas funcionam num browser e noutros ja não. Por isso é que decidi comecar a fazer o render no servidor mesmo, ate que os programadores dos browsers comecem a usar todos o standard do xslt.
----------------------------
if it bleeds, we can kill it |
| |
| | Boas.
"Deve estar optimizado para msxsl :->"
Não está não. Foi feito a pensar em todos os browsers. O problema é que já foi feito à prai 2 anos atrás, e entretanto ficou sem manutenção.
O "rendering" no servidor tem uma grande desvantagem: consome demasiado processador. Na altura a primeira aproximação do parser xsl levava uns 30 segundos a completar o rendering da primeira página. Depois lá se conseguiu baixar aquilo para +/- 1 segundo, e utilizando um sistema de cache o nº possível de hits por segundo disparou. Ainda chegámos a compilar o Xalan, mas a montanha pariu um executável de 50 e tal MB's, lols.
O Mário diz que é intragável e ilegível e tem razão. De facto a única coisa fixe naquilo era a possibilidade de poder gerar "conteúdo" em vários formatos mudando apenas a "stylesheet", além de dar uma certa "adrenalina" por na altura não existir nada feito naquilo em portugal e mesmo no resto do mundo ( encontrar exemplos, howto's, etc, foi dificil ). No entanto, o combo css+x(html|ml) passado uns tempos fazia o mesmo, de forma mais simples.
Pena é que ainda tenhamos tantas diferenças na interpretação de css's nos vários browsers.
@734, Nbk
|
| |
| | Nada no resto do mundo há 2 anos ?? Já estavamos em 2002. Que motor de busca usaram ?? :)
|
| |
| | Não percebo a opção por fazer o processamento do lado do cliente ?! Que tal usar o servidor?
|
| |
| | | Se precisas de perguntar é porque não precisas de saber. Cumprimentos Mario Valente
|
| |
| | Quando se querem usar tecnologias só por ser "fashion" sem pensar na carga que isso acarreta para os servidores é o que dá... bhaa
|
| |
| | | Já tens a resposta à tua pergunta... Cumprimentos Mario Valente
|
| |
| | Nao gostamos. Dá mais trabalho e tem mais desvantagens (ie totalmente ilegivel e ingerivel) do que vantagens.
O BlogDot já foi feito com XML+CSS que é um combo *muito* melhor.
Ora nem mais. Disseste tudo.
|
| |
| | Andei a fazer umas experiências com XSLT e achei muito fixe para gerar conteúdos web, tens separação dos dados e da template e ainda tudo isto separado dos estilos (ficheiros xml, xslt e css), também achei que é uma solução fixe para gerar conteúdos dinâmicos para web separando o código das templates (gera-se XML dinâmicamente e a template XSLT é aplicada a esse XML), o único senão é que o formato XML não me agrada muito por ser, díficil de processar(o código para processar XML tende a ser trabalhoso e entediante), pesado para processar e de díficil leitura por humanos quando a quantidade de dados é grande.
"Para mim a tecnologia é como as tangerinas, na medida em que não consigo fazer uma analogia decente sobre nenhuma das duas neste momento" Scott Adams |
| |
| Hmm... (Pontos:2, Interessante) |
| | | É curioso ter surgido este tópico, por eu próprio estava a fazer umas experiências com XML+XSL. Já que o processamento é feito todo do lado do servidor, então, está tudo bem. As desvantagens, são bem óbvias: mais uma camada para ser processada (mais lento), uma nova "linguagem" a ser aprendida, mais um sítio onde pode dar buraco. Por outro lado, o tempo que isso demora a ser processado é trivial. Aposto que qualquer "motor" de templates (Smarty, Cheetah, ...) é muito mais pesado do que isso, mas note-se que os usos não são os mesmos, embora sejam coincidentes nalguns casos. Em termos de "linguagem", aquilo é uma brincadeira (tens um for-each, condições como o 'if-then-else', 'switch-case' e pouco mais), e o facto de também poder dar buraco aí, é sinal de que temos mais um nadinha de modularidade, não é? :) Vamos lá entender, a performance nunca é de deitar fora, mas a utilização de XSLT pode-se justificar em muitos casos, sendo a criação de páginas um deles. Se há conhecimentos técnicos suficientes, não se perde nada: cria-se o documento XML (dinamicamente, ou não), é transformado com o XSL, e temos aquilo em formatos bastante interessantes (creio que até PDFs é possível criar dessa forma). Além do mais, um dia que queiras manter o teu website actualizado com os standards, é só mudar umas linhas no documento XSL, e estamos prontos. Aquilo, não é ilegível. Como tudo, pode ser mais ou menos legível, dependendo da experiência da pessoa que lê o documento, da qualidade do editor e da pessoa que escreveu o documento (comentários!!! o problema é que como acham que é markup, não necessita de comentários!!!). Acho que funciona como uma óptima camada de abstração entre o conteúdo original, e o formato final pretendido. Se isso não te diz nada, esquece. Se achas importante, por que tens conteúdo em XML que podes querer vir a dispor noutros formatos (o que é o mais normal, se não por quê usar XML sequer e não usar directamente (X)HTML?!), então vai em frente. Uma nota final: se quiseres utilizar, começa por um site pequenino (a tua página pessoal?), de forma a tomares noção real do que se trata. Vê por ti próprio, já que algumas das reticências que vi aqui, podem ser partilhadas por ti.
|
| |
| |
| | Já que o processamento é feito todo do lado do servidor, então, está tudo bem.
Discordo a 200%. Aumentar o processamento do lado do servidor é uma péssima escolha. A menos que tenhas meia duzia de hits por dia.
Já viste isso em produção num site com trafego de gente grande? Até mete pena.
As desvantagens, são bem óbvias: mais uma camada para ser processada (mais lento), uma nova "linguagem" a ser aprendida, mais um sítio onde pode dar buraco.
Tás a entrar em contradição. Mas tiveste certo nesta frase.
Por outro lado, o tempo que isso demora a ser processado é trivial.
Não, não é.
Aposto que qualquer "motor" de templates (Smarty, Cheetah, ...) é muito mais pesado do que isso
Não, não é.
Vamos lá entender, a performance nunca é de deitar fora, mas a utilização de XSLT pode-se justificar em muitos casos, sendo a criação de páginas um deles.
Tens dezenas de motores de templating que são muito melhores escolhas.
Como falaste no smarty, dou-te alguns pontos em que arrasa com o XSLT:
* é muito mais fácil de ler (distiguir quais tags são comandos e quais são XHTML não é muito fácil, pois não?)
* não te obriga a usar HTML que seja XML válido (podes manter o HTML4 se te apetecer)
* não te obriga a declarar no template variáveis que vais importar
* podes limitar a "linguagem", e dar apenas as possibilidades que te apetecer
* podes expandir a linguagem com plugins
* tens o problema de caching já resolvido para ti
Não vejo uma única vantagem na utilização de XSLT para templating de sites.
XSLT é bom noutros casos, Docbook é um bom exemplo disso.
|
| |
| | | Há sempre trocas a serem feitas. Eu acredito que a flexibilidade trazida pelo XSLT seja uma boa escolha em relação à lentidão. As opiniões podem divergir, mas eu acho que um site que tenha milhares de hits esteja mais preocupado com as despesas de largura de banda do que com as do hardware (embora ambas sejam a considerar). Não há contradição alguma no que eu disse: há sempre um impacto na performance. Continuo a afirmar que a lentidão não é significativa. A utilização de bibliotecas como o GD (geração de imagens dinamicamente) pesa muito mais do que uma transformação utilizando XSL, e não vejo ninguém a refilar por causa disso. A leitura e transformação dos documentos utilizando XSL, normalmente, é feita utilizando bibliotecas compiladas em C, por exemplo, e acho que isso, na maioria das circunstâncias e tendo em conta as tarefas em causa, é muito mais rápido a ser processado que qualquer biblioteca de templates escrita em Python ou PHP. Ainda assim, eu recordo-me de referir que XSL não é um substituto para os motores de templates, já que esses têm o seu uso específico. Ainda assim, para um bom exemplo da utilização de XSL+XML, vê o feito do gentoo. É este tipo de flexibilidade e conveniência que podemos obter com XSLT. E não percebo por que é que as pessoas aqui continuam permanentemente em pânico com a performance. As únicas pessoas que eu conheço que se preocupam com isso, além dos meus amigos 1337, são aquelas que programam sistemas críticos. Se calhar em Portugal o mercado anda mesmo mau, mas, normalmente, sai mais caro o programador perder horas a "optimizar" a performance da aplicação, do que comprar o hardware correspondente para o mesmo efeito. Moral da história: se o XSLT pode poupar trabalho, por que não utilizá-lo? O cliente agradece e tu também. :)
|
| |
| | Eu acredito que a flexibilidade trazida pelo XSLT seja uma boa escolha em relação à lentidão.
Qualquer lib de templating decente tem tanta ou mais flexibilidade que o XSLT. Passa uma vista de olhos na diagonal nos docs do smarty.
As opiniões podem divergir, mas eu acho que um site que tenha milhares de hits esteja mais preocupado com as despesas de largura de banda do que com as do hardware (embora ambas sejam a considerar).
Quanto tens hits mesmo a sério, qualquer coisa que leve mais 1 segundo a processar, vai-te custar máquinas novas para balancear a carga. Isso NÃO é uma escolha (para um manager com cérebro, claro) quando tens N maneiras de fazê-lo sem custos adicionais.
A utilização de bibliotecas como o GD (geração de imagens dinamicamente) pesa muito mais do que uma transformação utilizando XSL, e não vejo ninguém a refilar por causa disso.
Pois não. Se calhar é por não haver sites inteiros gerados em GD.
Ainda assim, eu recordo-me de referir que XSL não é um substituto para os motores de templates, já que esses têm o seu uso específico.
Nem mais. Esse é o principal problema. Muita gente que descobre a tecnologia fica com a tesão do mijo para a experimentar e a primeira coisa que lhes vem à cabeça é meter isso a fazer templating web.
Ainda assim, para um bom exemplo da utilização de XSL+XML, vê o feito do gentoo.
É este tipo de flexibilidade e conveniência que podemos obter com XSLT.
Volto a repetir-me. Não ganhas nenhuma flexibilidade ou conveniência que não ganhasses (a dobrar) com um outro qualquer sistema de templating.
E não percebo por que é que as pessoas aqui continuam permanentemente em pânico com a performance.
Porque quando se trata de web toda a performance é critica. Numa aplicação desktop se o processo demorar mais 2 ou 3 segundos não há problema, na web se tiveres 100 gajos simultaneos são 100*2 segundos. Faz as contas.
As únicas pessoas que eu conheço que se preocupam com isso, além dos meus amigos 1337...
Eu diria que os teus amigos são pessoas sensatas.
normalmente, sai mais caro o programador perder horas a "optimizar" a performance da aplicação, do que comprar o hardware correspondente para o mesmo efeito
Sim, mas repetindo-me de novo: sai ainda mais barato se utilizares tecnologia que já foi optimizada por alguem a pensar no "use case" específico com que te deparas.
Comprar mais hardware porque alguém insistiu que XSLT é o melhor devia ser causa justa para despedimento por incompetência.
Moral da história: se o XSLT pode poupar trabalho, por que não utilizá-lo? O cliente agradece e tu também. :)
Isso é falso. Não te poupa trabalho nenhum, antes pelo contrário. Já senti isso na pele, mas não vou discutir isso aqui.
Se tivesses usado ambos (templating vs XSLT) saberias que o teu post é tendencioso.
|
| |
| | Parece-me que uma das desvantagens mais apontadas aqui é a performance. Sobre isto gostava de dar uma achega...
O Apache tinha um módulo pouco suportado que tinha um comportamento interessante. Quando um documento HTML era pedido em determinados URLs ele ia ver se o HTML já existia e se era mais recente que o XML que lhe deu origem. Se não existisse ou se fosse mais antigo processava o XSLT e gerava o HTML gravando-o.
Gostei da ideia... cheguei a fazer algo semelhante mas em PHP. Não se torna lento e mantém as vantagens. E claro fica completamente compatível com os browsers.
Cumprimentos.
|
| |
| |
| | Boas.
"Gostei da ideia... cheguei a fazer algo semelhante mas em PHP."
Experimenta olhar para a source do siteseed. Algures lá para o meio existe um sistema de cache com a sua piada, que faz +/- aquilo que descreves.
@752, Nbk
P.s. - Não tenho a certeza, e não vou perder tempo a confirmar agora se é no siteseed ou noutro qq.
|
| |
| | Experimenta olhar para a source do siteseed. Algures lá para o meio existe um sistema de cache com a sua piada, que faz +/- aquilo que descreves.
Eu sugiro antes olhar para as classes do PEAR. Tem mais olhos e mais mentes por trás.
|
| |
| | O Apache tinha um módulo pouco suportado que tinha um comportamento interessante. Quando um documento HTML era pedido em determinados URLs ele ia ver se o HTML já existia e se era mais recente que o XML que lhe deu origem. Se não existisse ou se fosse mais antigo processava o XSLT e gerava o HTML gravando-o.
Parabéns. Descobriste as caches.
Gostei da ideia... cheguei a fazer algo semelhante mas em PHP. Não se torna lento e mantém as vantagens. E claro fica completamente compatível com os browsers.
Parabéns novamente.
|
| |
| | O Gildot está com a página inicial congelada outra vez. Este artigo aparece sem a indicação de haver comentários há já uns dias.
-- Carlos Rodrigues
|
| |
| |
| | E se nao estiverem logged in, nao se ve nenhum comentario.
|
| |
| | Ve isto: http://cocoon.apache.org/
Para quem vem do mundo Unix.. evidente!
|
| |
| |
| | Ve isto: http://cocoon.apache.org/
Para quem vem do mundo Unix.. evidente!
Prerequisites
You will need a JDK (Java Development Kit) installed on your computer, and (obviously) an Internet connection to download Cocoon.
Ui... XML + Java. Mistura killer. Algo que diz que isso não é muito rápido.
|
| |
| | Não é a ti que tem de dizer que é rápido. É por exemplo a uma das maiores empresas de telecomunicações do mundo.
40 milhoes de clientes (ou 400 mil dependendo do país), 30 outputs diferentes de wml, xhtml, html e svg, 20ms por request, etc
E tudo com JAVA, XSL e SVG. Como o Cocoon usa SAX para processar o XML, mais um XSL ou menos um XSL pelo caminho é quase irrelevante.
A maior vantagem da separação entre conteudo (XML) e output (XSL) é quando se quer gerar multiplos outputs para multiplos devices.
E não, perl ou php não são solução para estes casos...
|
| |
| | Não é a ti que tem de dizer que é rápido. É por exemplo a uma das maiores empresas de telecomunicações do mundo.
Claro. Se perguntares à Compaq a velocidade do laptop que queres comprar, eles respondem-te que só revelam isso a empresas da fortune 500.
Tomaste os medicamentos?
40 milhoes de clientes (ou 400 mil dependendo do país), 30 outputs diferentes de wml, xhtml, html e svg, 20ms por request, etc
De que raio estás a falar?
E tudo com JAVA, XSL e SVG. Como o Cocoon usa SAX para processar o XML, mais um XSL ou menos um XSL pelo caminho é quase irrelevante.
Phear. Passou-se.
"mais um XSL ou menos um XSL [...] é quase irrelevante"
O SAX já não usa CPU??
A maior vantagem da separação entre conteudo (XML) e output (XSL) é quando se quer gerar multiplos outputs para multiplos devices.
Mais um cérebro condicionado para interiorizar tudo o que o corporate debita.
A separação de conteudo e output não é nenhum problema recente. É muito anterior ao XML/XSL. E existem N soluções que resolvem isso.
A solução está no design da aplicação e não na tecnologia usada.
Não acredites em tudo o que te dizem.
Revolution will not be televised.
|
| |
| | alguma razao especial para o gildot andar tao parado?poucos comentários, pouquíssimos artigos..
|
| |
