Há poucos dias atrás foi ao ar o TattooJar, que é um site desenvolvido em Rails por um amigo pessoal de longa data.

Conforme o nome indica, o TattooJar é um site focado em tatuagens, ou mais especificamente em compartilhar fotos de tatuagens. Portanto, se você tem ou viu alguma tatuagem legal, ou está procurando algumas idéias para fazer uma, já sabe aonde ir.

Em relação a parte técnica, o site, conforme já foi dito, foi desenvolvido com o Rails, mais precisamente com a versão 2.0.2. Além disso, ele também usa o RMagick e o will_paginate, e está no ar através de um shared hosting na Dreamhost, sendo distribuído por um Apache com Fast CGI.

Ontem eu estava trabalhando em um pet project que provavelmente nunca verá a luz do dia, e me deparei com a necessidade de criar um campo de texto não editável. Como a minha memória não é muito boa, se é que eu já vi como se faz isso algum dia, eu não consegui me lembrar de como proceder. Sendo assim, eu consultei a documentação da API do Rails, mas não fui bem sucedido, portanto pesquisei em alguns sites logo em seguida, e, após um certo tempo, descobri o que eu queria. Como forma de reforçar isto na minha memória, e também para tentar ajudar os próximos que fizerem a mesma busca no Google, eu estou postando agora como fazer isso.

No meu caso específico, este campo de texto que não poderia ser editado estaria em um típico formulário de preferências de um usuário, onde ele poderia editar coisas como senha e email, mas não poderia editar o campo de login. É claro que poderíamos simplesmente deixar este campo ser editado no formulário, e quando este fosse enviado, simplesmente ignoraríamos qualquer alteração no login, além de gerar uma mensagem informando tal comportamento. No entanto, um dos princípios de uma boa interface é não criar situações que possibilitem erros. Se bem que seguindo essa linha de raciocínio eu nem deveria colocar o campo login no formulário, já que ele não pode ser editado mesmo, mas se fosse assim não teríamos este post, então vamos ignorar este pequeno detalhe.

Abaixo está o código do formulário mencionado, sendo que a parte relevante, pelo menos no escopo deste post, é a linha <%= f.text_field :login, :disabled => true %>, que, como vocês devem imaginar, desabilita a edição deste campo do formulário.

P.S.1: É evidente que um formulário de preferências de verdade teria 3 campos para senhas(senha atual, nova senha e confirmação da nova senha), mas pra simplificar o exemplo, e focar apenas no que interessa neste post, eu reduzi o formulário.

P.S.2: Ninguém pode negar o meu enorme talento para enrolar, já que poderia resumir o conteúdo deste post inteiro na seguinte frase:

Para criar campos de texto não editáveis no Rails basta incluir :disabled => true como argumento do helper text_field.

Objetividade é para os fracos! :)

Conforme mencionei alguns dias atrás, recentemente eu comprei o Repensando a web com Rails, do Fabio Akita, e ontem, ao ler a entrevista com o Yukihiro “Matz” Matsumoto no apêndice 2 do livro, reparei em um detalhe sem muito importância, mas ainda assim interessante.

Em um certo momento, o Akita pergunta sobre o lançamento do Ruby 2.0, e o Matz responde que o próximo grande lançamento do Ruby (1.9 ou talvez até 2.0, segundo ele) sairia mais ou menos no Natal de 2007. E adivinhem quando saiu o Ruby 1.9? Exatamente no Natal de 2007!

Ou seja, o Matz fez uma previsão incrivelmente precisa mesmo 1 ano e 2 meses antes do lançamento da versão 1.9 do Ruby, já que o livro do Akita foi lançado em outubro de 2006, sendo que a entrevista pode até ter sido feita um pouco antes disso.

Portanto, é melhor levar a sério quando o Matz fizer uma previsão sobre o lançamento de uma versão do Ruby.