Introduza o termo a pesquisar e clique Enter.

Tag: tvwall

JSON/HTML/XML – Qual devolver?

Nov 10 16

Escrito por Luis Nabais @ 16/11/10 21:11 | 2 Comentários »

Bem este post vai servir não só como uma forma rápida de apanhar algumas opiniões como também para ficar com uma nota para mim próprio sobre esta ideia.

Para o meu TV Wall estou a tentar ir o mais longe possível no juntar da API da aplicação com o que efectivamente é visível para os utilizadores e parte disso passa por tentar ter praticamente o mesmo esquema de URLs tanto para o browser como para a API utilizada pelos mais diversos clientes (quer seja a própria aplicação web em javascript ou outra qualquer hipotética aplicação nativa). Isto faz com que os endereços se tornem por exemplo em algo como /show/house para aceder, neste caso, à pagina associada à série House.

Agora o desafio: como fazer o mesmo endereço devolver HTML para um browser mas JSON (ou XML ou qualquer outro formato de dados) para uma aplicação? A minha resposta passa pelos cabeçalhos HTTP, mais concretamente pelo cabeçalho ACCEPT que ao anunciar que aceita um determinado tipo de dados permite-me devolver-lhe esse tipo em particular deixando o HTML normal para fallback.

Claro que eu posso já começar a ver os problemas associados a esta abordagem: e se surgir um browser que manda um cabeçalho a dizer aceitar application/json quando o que o utilizador quer mesmo receber é a versão HTML? E se um cliente enviar no cabeçalho que aceita tanto JSON como XML? Qual dos dois devolver? Sim, isto são tudo questões muito validas e é por isso mesmo que coloquei esta entrada no meu blog. Opiniões?

One small step for me

Nov 10 09

Escrito por Luis Nabais @ 09/11/10 21:11 | 1 Comentário »

TVWall Code Bem isto realmente pode não parecer muito emocionante e até excessivamente lento para a maioria mas a minha vida tem andado tão caótica ultimamente que mesmo este pequeno avanço me deixa bastante entusiasmado.

Como certamente sabem tenho andado a brincar com um pequeno website cujo único factor particularmente distinguível é, perdoem-me a modéstia, o design. Agora este post serve apenas para dizer que dei hoje finalmente os primeiros passos para o rewrite que tenho andado a planear e que deve finalmente tornar a aplicação utilizável no dia a dia.

Ficou finalmente funcional a primeira chamada da futura API do TV Wall (sim, vai existir uma API) e apesar de ainda faltarem alguns detalhes (como por exemplo uma forma de autenticação) é já uma conquista para mim conseguir ter posto a funcionar um pedido a um serviço externo e respectiva cache local em CouchDB.

Com isto tenho vindo a habituar-me ao conceito de programação por eventos o que leva a casos curiosos em que passo um bom bocado a tentar perceber porque é que este código não funciona apesar de ao inspeccionar o objecto o método ser claramente visível.

if (db.table.exists()){}

A resposta é simples quando se começa a compreender a linguagem (se bem que um pouco de documentação teria ajudado neste caso): o método é assíncrono pois vai questionar uma base de dados externa logo a forma correcta de o fazer é deixando um callback que vai ser chamado quando ela responder.

db.table.exists(callback = function(result) {
    if (result) {
        // Exists
    } else {
        // Does not exist
    }
});

Como podem ver isto não é propriamente das coisas mais simples de se usar para programação mais convencional em que estamos dependentes do resultado mas para programar na web onde temos de responder a múltiplos pedidos simultaneamente e estamos dependentes dos mais diversos pontos de latência este tipo de lógica trás teoricamente vantagens interessantes para a performance do sistema.

Node.js não é propriamente simples e está bastante longe de estar maduro mas promete bastante na minha modesta opinião e acho que é uma boa aposta para o futuro próximo da web.

PS: acho que é a primeira vez que mostro aqui o novo logótipo do TV Wall. O que acham?

Os misteriosos 3px em css

Ago 10 14

Escrito por Luis Nabais @ 14/08/10 23:08 | Sem Comentários »

Eu tenho andado a trabalhar em correcções e melhorias do código HTML/CSS do meu TV Wall já há uns tempos para me permitir fazer coisas ainda mais awesome (como drag & drop por exemplo) mas noutro dia deparei-me com um comportamento curioso da renderização de css que me demorou algum tempo até compreender o seu porquê (e na verdade ainda só tenho uma teoria não comprovada).

O problema em questão é o seguinte. Notem a imagem seguinte:

Isto é a típica composição de uma “parede” no TV Wall. Cada um dos rectângulos na imagem é uma célula contida em caixas maiores marcadas a castanho e possuindo cada uma destas ultimas display: inline-block;. Esta organização é uma necessidade por forma a permitir não só que os tamanhos das células sejam variáveis como também para as organizar nas diversas formas pretendidas e ainda para permitir que a parede cresça consistentemente em vez de crescer até ao limite da largura antes de passar para a linha de baixo.

O problema coloca-se com a pequena linha a branco que podem ver na imagem. Cada uma das caixas a castanho é suposto possuir 40em de largura e não possuir qualquer margin ou padding (por questões de consistência que auxiliam nas operações que planeio fazer em javascript) no entanto na realidade todas as caixas possuíam uma “margem” invisível de 3px à sua direita.

Na realidade isto não é nenhuma margin ou padding mas sim uma propriedade chamada de letter-spacing que por defeito no Firefox e no Chrome possui o valor de, lá está, 3px! Porém não consegui corrigir o problema alterando esta propriedade no antecessor das minhas caixas, simplesmente ficava tudo na mesma. A solução passa por algo infinitamente mais simples: colocar cada uma das caixas com float:left; display: block; e presto, os 3px desaparecem e a previsibilidade regressa.

O facto do letter-spacing ser a causa desta situação é apenas uma conclusão a que cheguei visto estar a usar inline-block em vez de um simples block + float como devia ter feito desde o inicio efectivamente complicando a minha situação. Fica no entanto o aviso para outros que possam estar a encontrar o mesmo problema e já agora se eu me tiver enganado na minha conclusão façam favor de me avisar.

Javascript no Servidor

Jul 10 06

Escrito por Luis Nabais @ 06/07/10 3:07 | 8 Comentários »

Como tinha dito antes tenho andado a brincar com algo que apelidei de TV Wall e essa brincadeira passa principalmente por usar JavaScript e funcionalidades novas do HTML5…

Pois bem, aplicações web a correrem praticamente só no cliente são muito giras realmente mas infelizmente ainda são precisas algumas coisas do lado do servidor e para essas tenho andado a usar o bom e velho PHP… E php serve, php dá para responder a pedidos, php cumpre a sua função admiravelmente e acima de tudo php funciona de uma maneira que eu compreendo muito bem: eu aponto-lhe um url e ele corre o script que se encontra nesse url. Serve perfeitamente mesmo que não seja a solução mais moderna ou a que escale da melhor forma.

Mas eu não quero usar php e tenho andado a apaixonar-me cada vez mais com JavaScript. Acima de tudo eu gosto da ideia de que uma aplicação não corre mas sim responde a pedidos. As aplicações não passam variáveis, passam mensagens (e essas mensagens são em JSON no meu caso). O que eu queria mesmo era usar JavaScript em todo o lado e guardar todos os meus dados em JSON.

Guardar os dados já consigo, tenho o belo do CouchDB a deixar-me guardar lá objectos JSON com uma bela api via REST, mas a minha grande duvida é como raios vou usar javascript no servidor…

Temos o Node.js, o Narwall com o Nitro, temos o Ringo e mais uns quantos e a verdade é que eu estou totalmente perdido… Eu não só não sei em qual deles pegar como não faço a mais pálida ideia de como começar a programar o que quero que ele faça… Alguém me consegue dar uma ajudinha?

pub: