O WordPress hoje conta com uma API (Application Programming Interface) para dar suporte ao desenvolvimento de plugins que facilita as coisas de um modo incrível, tornando a tarefa de escrever um plugin algo bastante tranquilo, sem grandes dificuldades e sem interferir no funcionamento do núcleo do WP. Usando o que eles chamaram de "Hooks" (ganchos) podemos definir funções para serem executadas em momentos específicos a execução do WordPress, quando o usuário fizer isso ou aquilo ou filtrar conteúdos antes que sejam enviados para a tela.

O que é um plugin?

Um plugin, por definição, é um programa que se conecta em outro para ampliar as funcionalidades ou resolver problemas deste segundo. Normalmente um plugin para WordPress adiciona ou modifica algo no conteúdo ou na apresentação do blog e oferece uma interface para configurações e/ou outras ações na administração do WP.

Ao construir um plugin para qualquer aplicativo, há certos cuidados que deveríamos tomar.

• Evite colisões de nomes de funções e variáveis
  é prudente usar um prefixo em todos os nomes, como "myplug_"
• Não modifique arquivos originais do programa
  para não haver problemas se o plugin for desinstalado
• Crie um sistema de desinstalação
  evitando deixar arquivos perdidos ou dados inúteis poluindo a database se o plugin for desinstalado
• Evite erros desnecessários de imcompatibilidade
  testando pela existência de variáveis, funções e classes antes de tentar usá-las no seu código

A estrutura do plugin

Para ser aceito como um plugin utilizável, há apenas uma exigência: é preciso criar um cabeçalho segundo certas regras, como descrito aqui (em inglês). Veja um exemplo:

Após inserir esses dados no seu arquivo (.php) e colocá-lo em "…/wp-contents/plugins/" ele já estará disponível na página de gerenciamento de plugins da administração do WP.

Esse cabeçalho deve ser colocado apenas no arquivo principal do plugin e deve estar no diretório citado acima, solto ou em um subdiretório, como em "…/wp-contents/plugins/myplug/myplug.php". Não importa o nome que você der ao arquivo, o WP vai procurar por algo semelhante ao cabeçalho mostrado acima em todos os arquivos PHP no diretório pluins e em seus subdiretórios (apenas um nível).

Naturalmente, um plugin pode ter vários arquivos, mas tudo deve ser detonado a partir do arquivo principal, que contém o cabeçalho. É ele que vai ser executado se o plugin estiver ativado.

O que faz o seu plugin?

Existem centenas de plugins para WordPress disponíveis na web, alguns super bem feitos, outros nem tanto… Antes de iniciar seu plugin, busque na rede. Talvez haja algo pronto que atenda às suas necessidades.

Mas se você teve uma idéia genial ou tem uma necessidade específica, mantenha em mente o seu objetivo e mãos à obra!

Entendendo os Hooks

Há dois tipos de ganchos para usar em seu plugin:

• Actions (ações) referência (inglês)
  As actions nos dão a possibilidade de executar funções em situações determinadas da execução do WordPress, como ao escrever um post, ao editar um post, etc.
• Filters (filtros) referência (inglês)
  Os filters permitem literalmente filtrar a sáida de dados do WP. Podemos por exemplo procurar por ":)" no texto dos posts e substituir por um smile em imagem (claro que isso já existe…) . Nesse caso, nossa função recebe o texto do post depois de processado pelo WP e antes de ser impresso na tela, processa e retorna, só então o texto é exibido.

Para usar actions e filters existem duas funções específicas, que recebem parâmetros iguais:

Há dois parâmetros opcionais relativos à prioridade para a execução da função e aos parâmetros recebidos por sua função, mas nem falaremos deles - apenas os dois primeiros são obrigatórios e são suficientes. Quando sua função for executada, estará literalmente "dentro" do WordPress, com acesso a funções e variáveis. Antes de sair escrevendo, consulte a referência de funções do WP e, se necessário, vá olhar a função sobre a qual tiver dúvidas. Isso evitará a construção de funções redundantes, diminuindo consideravelmente seu código - o WP tem muitas funções úteis e disponíveis. Quanto às variáveis, vale dar uma pesquisada para encontrar os dados que procura… tudo está "flutuando" nas variáveis globais do WP.

A linha de código abaixo vai retornar um resultado enorme, mas vai te ajudar a achar o que procura. Muitos dos valores estão em objetos, como em $post, que contém os dados de um post, e é importante lembrar que para acessar as propriedades não funciona a fórmula do array, como em $post[’ID’], o correto é $post->ID.

Ok, com os hooks posso executar qualquer coisa para implementar a funcionalidade proposta pelo meu plugin. Mas e para inserir uma página na administração do WP?

Inserindo uma página na administração do WordPress

Aqui a liberdade é total. Podemos criar um novo item no menu principal e depois criar subpáginas para esse tópico ou simplesmente criar uma subpágina para um item existente, como em Options, por exemplo - muito usado pelos plugins. Para fazer isso, usamos as funções:

add_menu_page(page_title, menu_title, access_level/capability, file, [function]);

add_menu_page adiciona um item ao menu principal. Essa opção nas últimas versões do WP pode ser desabilitada pelo administrador, portanto deve ser usada com cautela.

add_submenu_page(parent, page_title, menu_title, access_level/capability, file, [function]);

add_submenu_page adiciona um item a um tópico do menu principal, seja uma das páginas padrão do WP ou um tópico criado com add_menu_page().

Veja os parâmetros:

• parent -> o arquivo relativo ao tópico do menu principal - apenas para add_submenu_page()
• page_title -> valor que será aplicado ao título da página
• menu_title -> Rótulo do item que será inserido no menu
• access_level/capability -> nível ou capacidade do usuário
  Aqui definimos que usuários terão acesso às funcionalidades do nosso plugin (os níveis vão de 0 a 10 e as capacidades são: administrator, editor, author, contributor e subscriber).
• file -> o endereço do arquivo PHP que é a interface do plugin ou um ID (uma string de identificação) para a página, se você optou por usar o parâmetro seguinte (function)
• function -> o nome da função que inclui ou mostra a iterface do plugin.

Guardando seus dados

Seu plugin pode usar a database de duas formas:

• Criando tabelas no banco de dados

  Para criar suas próprias tabelas, é preciso seguir certas normas.

  • Talvez seja prudente antes de qualquer coisa tentar entender a classe wpdb - aqui (em inglês)
  • Não esqueça de que o administrador pode configurar um prefixo para as tabelas no banco, portanto é importante usar esse prefixo que está em $wpdb->prefix.
  • Use o hook "activate_[arquivo_do_plugin]" para chamar a função de instalação
  • Aqui é mais importante que nunca ter uma função de desinstalação, chamada através do hook "deactivate_[arquivo_do_plugin]"

   

• Usando as funções nativas do WordPress

  O WordPress oferece algumas funções para os plugins armazenarem informações no banco de dados, o chamado "Mecanismo de opções", que nos permite guardar variáveis serializadas no banco de dados. Essas variáveis podem ser de vários tipos, acho que até objetos (se você usar a propriedade mágica __SLEEP), sei lá. Veja as funções que implementam a idéia:

  • add_option(option_name, value, [description], [autoload])
  • get_option(option_name)
  • update_option(option_name, value, [description], [autoload])
  • delete_option(option_name)

   

  Os parâmetros

  As funções recebem parâmetros semelhantes, sendo que description e autoload são aplicáveis apenas
  • option_name -> nome da opção.
  • value -> valor (inicial ou novo valor) da opção.
  • description -> Uma descrição da opção sem muito uso prático. (opcional)
  • autoload -> pode-se usar esse parâmetro para definir se a opção será carregada automaticamente ou não. Também sem muito uso. (opcional)

Usando Javascript e CSS em seu plugin

O WordPress oferece duas funções para incluir o seu script automaticamente, carregando até bibliotecas como o prototype se você especificar, mas eu não pesquisei nem usei essas funções (wp_print_scripts, wp_register_script, wp_deregister_script e wp_enqueue_script - todas sem referência oficial).

Mas sem usar essas funções, como fazer? Simples. Como já foi dito, temos acesso à todos os "momentos" da execução do WP - isso significa que podemos escolher quando (e aqui quando quer dizer aonde) nossa função será executada. Estamos dentro do WordPress por assim dizer, qualquer print ou echo irá imprimir na página diretamente, então basta procurar o hook certo e imprimir o que precisamos na seção HEAD da página e o hook para isso é "wp_head" para as páginas do site e "admin_head" para as páginas da administração. Faríamos então algo assim:

Simples, né?

Internacionalizando seu plugin

Isso é necessário se você deseja compartilhar seu plugin com o resto do planeta e não apenas com os que falam português. O mais correto, de qualquer modo, seria escrever o plugin em inglês e então traduzir para o português brasileiro, para que seus clientes possam entender.

O sistema utilizado é o gettext da GNU e há duas funções que você deve lembrar, a __() que retorna o texto original (em inlês) traduzido para a linguagem selecionada pelo administrador do sistema e _e() que imprime a tradução diretamente na tela. Mas para os plugins, é preciso criar um text domain (uma palavra-chave que identifique seu plugin), no nosso exemplo, "myplug" - veja adiante. Então…

Você pode desenvolver seu plugin até o final sem se preocupar, apenas onde houver um texto legível, use as fórmulas acima. Mas a coisa ainda não funciona, pois precisamos agora carregar o domínio criado (myplug) e indicando o caminho para o diretório onde estará o arquivo myplug-pr_BR.mo, que criaremos em seguida. Para isso você precisará de um editor específico para arquivos .POT, .PO e .MO. Eu uso e recomendo o poEdit, mas não vou me alongar mais sobre ele - veja aqui ou aqui (em inglês) .

Após criar o arquivo POT inicial, basta atualizar que o programa vai ler e mostrar cada texto que foi enviado para as funções __() e _e(). Traduza e salve. Isso irá gerar o arquivo .MO, que deve ter um nome assim:

text-domain_do_pligin-linguagem escolhida.mo

Como por exemplo: myplug-pt_BR.mo.
Agora basta carregar o text-domian criado com a seguinte linha de código:

$dir_name = preg_replace("/^.+(\\\\|\/)/", "", dirname(__FILE__));
load_plugin_textdomain("myplug", "wp-content/plugins/".$dir_name);

Agora tudo deve estar funcionando.

Acho que isso vai ajudar bastante os que estão iniciando com o WP, esse programa fantástico. Boa programação e tenha sempre em mente a nota de rodapé do site do WordPress: CODE IS POETRY!

Alguns links interessantes (em inglês)

• codex.wordpress.org
• Functions reference
• WordPress Template Tags
• WPDB class reference
• Writing a Plugin
• WordPress Plugin API
• WordPress Actions
• WordPress Filters

Eu tenho um sistema de gerenciamento de conteúdo que chamei de WebEdit (nada original…) e embora ele ofereça uma ou duas funcionalidades que o WordPress não tem, me rendi e comecei a pensar em vender sites baseados no WP. Mas para fazer isso, precisava de alguns detalhes específicos para sites específicos. Fui buscar plugins para fazer o que eu presisava, mas me surpreendi ao descobrir que dentre os zilhões de plugins para WP disponíveis poucos são realmente confiáveis e desses nenhum fazia o que eu queria (a não ser dois que eram comerciais). Aí cheguei à conclusão óbvia que até uma criança veria: para vender sites baseados em WP é preciso dominar os templates e plugins.

O que eu precisava me parecia algo simples: usar os arquivos enviados como áreas de download e ter um sisteminha de mala-direta. Comecei analisando o plugin Organizer para resolver minha promeira questão - ele é bem maneiro, mas eu precisava de título e descrição para cada arquivo e de um sistema para exibir esses arquivos como uma área de downloads. Acabei fazendo uma coisa que não se deve fazer, modificando os arquivos originais do plugin que não fui eu que fiz… bem, com isso cheguei a uma versão não oficial do Organizer, o Organizer modified.

Quanto à mala-direta, achei alguns para enviar emails aos usuários outros à venda, bem, já estava no ritmo e resolvi escrever o meu próprio plugin. Por isso é que há tanto tempo não escrevo nada por aqui. Mas aqui estou eu e com um plugin para WP novinho em folha, o WPMailing. Pedi asilo para ele no novo site oficial de plugins do WP, o http://wordpress.org/extend, mas vou disponibilizar uma versão dele aqui.

O que se pode fazer com o WPMailing:

• Criar e gerenciar grupos de usuários
  (os grupos são, na verdade, tags - um mesmo usuário pode estar em vários)
• Enviar e-mails para os usuários por grupo, capacidade, nível ou login
• Enviar e-mails com arquivos em anexo, se necessário
• Usar valores personalizados do usuário que vai receber o e-mail
• Usar valores de uma publicação (post ou página) no e-mail
• Receber um relatório sobre o envio após cada e-mail enviado
• Pode-se usar os plugins Xinha4WP ou Dean’s FCKEditor

Baixe os plugins:

• WPMailing
• Organizer modified (baseado no Organizer)

Abraço a todos, Cau Guanabara

Apesar de parecer algo meio ambicioso para um cara sozinho, comecei a montar meu editor. Já possuía duas peças fundamentais: o script de tradução e um script para construir a barra de ferramentas, só me faltava o editor em si. Resolvi tentar e, para meu espanto, um mês depois o editor já existe. Cheio de falhas ainda, mas funcionando.

Como sabemos , essa é a fase mais chata de qualquer projeto… aparar arestas é um trabalho de chinês e fica pior quando não entendemos profundamente o tema de trabalho. Eu já tinha feito alguns plugins para o editor Xinha, mas não entrei na parte mais hard, onde acontece a edição em si. O controle de textRanges e selections é algo inteiramente novo para mim. Bem, já não inteiramente…

Construí um site e disponibilizei o WikiEditor para testes, tentando fazer outra coisa que nunca havia feito, apesar de ter desenvolvido inúmeros projetos durante os últimos anos: tratar o projeto como deve ser, com uma base na web, um changelog, controle de versão (nunca tinha utilizado…), etc. Tentei achar um host que oferecesse o Trac grátis, mas ainda nada. Tentei o sourceForge, mas meu ingrêis não deu…

O WikiEditor é ainda um neném, mas me parece que tem algum futuro possível. Dê uma olhada, faça uns testes e, se quiser, comente, entre em contato.

O sistema está disponível aqui: http://cauguanabara.jsbrasil.com/scripts/wysiwiki/demo/

ou se preferir navegar pelo código: http://cauguanabara.jsbrasil.com/scripts/wysiwiki/

Abraço, Cau Guanabara.

Vou mostrar aqui uma forma bastante simples e funcional de fazer isso em Javascript, com três funções apenas, mas antes de mostrar o código, vou explicar a idéia da coisa e desmistificar logo o "complicadíssimo drag and drop", antes que você se decepcione com o tamanho do código…

Bem, nossas funções vão explorar três eventos: onmousedown, onmousemove e onmouseup. Essa é a anatomia do "pegar, arrastar e soltar". Mas haverá certas condições para um elemento ser arrastável, pois o script precisa saber se o elemento em foco no onmousedown deve ou não seguir o ponteiro do mouse se ele andar (onmousemove) antes do onmouseup. Para isso, estabelecemos um nome de classe (CSS) padrão que transforma o elemento num elemento arrastável e esse nome é "drag". A classe drag pode ou não existir. Aqui usamos ela para definir o cursor como "move". Além disso, é preciso definir uma variável com o ID do elemento a ser arrastado, para o caso (frequente) de arrastar um elemento a partir de outro, como uma janela é arrastada a partir de sua borda superior.

Vamos começar declarando algumas variáveis necessárias e definindo os comportamentos relativos ao mouse na função initDragDrop:

Repare que as variáveis foram declaradas sem a instrução var, pois assim elas serão globais e estarão disponíveis para outras funções.
Sempre é melhor usar uma rotina tipo addEvent para definir os eventos. Da forma que está feito aqui, se houvesse algum comportamento definido para esses eventos, eles seriam substituídos pelos nossos.
Como trabalhamos com o elemento body, é preciso esperar o carregamento da página, portanto initDragDrop deve ser chamada no onload da página.

Desde a chamada da função acima, __dragMove passa a monitorar a variável __dragging, que só é true desde o momento em que clicamos em um elemento com a classe "drag" setada (__dragDown) até soltarmos o botão do mouse (função anônima definida para o evento onmouseup). Se __dragging é true, então passa a definir a posição do cursor para o elemento __dragEl, preservando a posição do mouse sobre o elemento.

Para __dragDown definir __dragging como true, dois testes devem ser feitos. O elemento clicado deve ter a classe drag e __dragId deve estar definido com um ID válido. Se o ID é válido, __dragEl passa a apontar para o elemento com esse ID.

Então, além da classe drag, colocaremos no elemento a ser arrastado (ou naquele que será a "alça de arraste") um comportamento no evento onmouseover definindo a variável __dragId. Veja o HTML:

Note que o primeiro div no mouseover aponta para si mesmo, enquanto o segundo será movido a partir do div com ID "Layer3".

Simples demais, não? Veja aqui uma página de testes.

Abraço, Cau Guanabara.

O CSS declarado inline, dentro da própria TAG, está facilmente acessível ao javascript, tanto para ler quanto para modificar. Podemos também ler e modificar com facilidade o valor da propriedade className das TAGs, alternando entre grupos de regras css pelos nomes das classes correspondentes. Mas, até pouco tempo atrás, havia para mim dois pontos incógnitos, duas perguntas que me perseguiam: "como modificar regras dentro de uma classe?" e "como obter as regras que incidem em determinado elemento por herança?". Bem, sou um autodidata e é essa curiosidade que me faz andar para frente, portanto, pesquisei e, como sempre, descobri que é simples. Aliás, essa é uma lição que posso dar aos iniciantes que são autodidatas como eu: difícil é aquilo que ainda não aprendemos a fazer, o resto é fácil. Não se deixe intimidar.

Como essas questões me incomodaram por bastante tempo, achei que valia escrever esse tutorial. Vamos lá, vou responder a elas da melhor maneira que conseguir.

Bem, naturalmente o javascript não pode modificar o que está escrito (hard-coded) no arquivo, mas entre a leitura das classes CSS declaradas na página e a renderização dos elementos a partir delas, o navegador faz mais do que sonha a nossa vã filosofia… e o fato é que o documento é rederizado com base em um objeto que contém as regras CSS lidas e não no texto-base do documento exibido. E este objeto (document.styleSheets) pode ser lido e modificado! Sua anatomia é complexa e prá variar (mesmo nesses tempos de padronização), muda de um navegador para outro. Mais correto seria dizer "de um navegador para os outros"… mas deixa prá lá. Vamos tentar concentrar em áreas acessíveis aos dois (Mozilla e IE).

A primeira propriedade que precisamos entender é o length, que está disponível em todos os browsers e faz referência aos elementos de estilo existentes no ducumento. Estou falando das duas TAGs que são usadas para esse fim: <STYLE> e <LINK>. No documento que você está vendo há o seguinte CSS:

Bem, temos um elemento STYLE e um elemento LINK, portanto a propriedade document.styleSheets.length será igual a 2. A eventual presença de um @import url(…) dentro de um elemento STYLE não iria interferir na propriedade length, mas numa outra propriedade, da qual não trataremos aqui: imports.

Os elementos do objeto são idênticos para regras adquiridas de arquivos CSS externos ou de elementos STYLE declarados na própria página e a forma de reconhecê-los é pela propriedade href, que não existe em TAGs STYLE. A propriedade href do objeto document.styleSheets[_INDICE_], por outro lado, existirá em todos os elementos, mas para as TAGs STYLE o IE devolverá uma string vazia e o Mozilla, a URL do arquivo atual (…?).
Outra forma é usar o atributo owningElement (IE) / ownerNode (Moz), que aponta para uma referência ao nódulo DOM relativo à TAG em questão. Daí basta usar o atributo tagName. Veja:

Dessa forma, já pegamos os valores que queríamos e já podemos modificar as classes e regras em geral pelo atributo cssText (a declaração textual de todas as propriedades contidas em determinada regra). A sentença abaixo…

E com isso repondemos à nossa primeira questão, certo?
Veja aqui um script mais completo para manipular os estilos na página.

Mas ainda restou a outra pergunta…

A real dificuldade aqui é que não basta ler os estilos inline e as classes CSS declarados na TAG, pois um elemento pode, além disso, herdar do seu elemento-pai ou de um ancestral qualquer, uma grande quantidade de regras que, apesar de não estarem explicitamente declaradas na TAG, incidem sobre a renderização visual do elemento.

Bem, essa resposta é mais simples mas, mais uma vez, formas diferentes para navegadores diferentes… O IE disponibiliza uma propriedade no nódulo DOM dos elementos, a currentStyle que engloba todos os estilos a incidir sobre o elemento. Já no Mozilla precisamos usar um método do objeto document.defaultView, o getComputedStyle(). Bem, para facilitar vamos construir uma funçãozinha crossbrowser, a getCurrentStyle(). Veja:

O elemento acima é um PRE apenas com a classe codigo definida e o id "codetest". Na classe codigo não há definição para a cor da fonte, mas ela é exibida com a cor "#333" por herança da da classe definida para a TAG BODY. Veja na prática:

O objeto de retorno da função acima pode ser enorme, pois inclui todas as propriedades específicas de cada navegador e, no caso do Mozilla, até funções. Por isso nosso exemplo foi direcionado a uma propriedade escolhida (color) e recomendo que você faça da mesma forma, para evitar dores de cabeça. Senão, teste o valor de cada item e ignore strings vazias e funções… isso vai melhorar um pouco a confusão.

Atenção!
Este tutorial leva em consideração apenas os navegadores da família Mozilla e o Internet Explorer.

Escrevi este texto em casa, sem pensar em publicar aqui no blog, por isso fui mesclando o texto com javascript para ter exemplos alive, mas as restrições do wordpress não permitem javascript. Além disso, os estilos declarados eram específicos para os testes pensados, enfim…

O resultado disso tudo é que a "versão completa desse post" está em uma página separada. Aqui temos apenas uma cópia sem correspondência com o JS ou CSS dessa página.

Clique aqui para ler o texto com exemplos

Abraço a todos, Cau Guanabara

O texo acima foi retirado da wikipedia e diz, em outras palavras, que o termo "wiki" é utilizado para definir websites colaborativos como a própria wikipedia (wikipedia, livremente interpretado, significa "enciclopédia colaborativa") ou os aplicativos usados para gerar esses sites.

Definido o que é "wiki" vamos ao "wiki-format" ou "formato wiki". Juntamente com essa idéia de colaborativizar a internet, surgiu um problema: como gerar o HTML necessário para ser exibido quando um usuário leigo quiser criar ou editar algum conteúdo? Os editores de HTML online são coisa nova e poucos funcionam a contento… Surgiu a idéia de gerar a formatação HTML a partir de certas combinações de caracteres comuns como apóstrofos, acentos, vírgulas, etc.

Existe uma gama enorme de aplicativos (web-based e de desktop) para gerar e manter conteúdos participativos na internet (veja aqui alguns) e a quase totalidade deles trabalha com algum tipo de formatação wiki, embora os sinais escolhidos variem um pouco - mas poucos ou nenhum em javascript. Descobri por que precisei de um tradutor wiki para usar em um sistema de comentários que é parte de um outro projeto… bem, não importa. O fato é que não achei nada em javascript que pudesse utilizar, então resolvi escrever o meu próprio wiki<=>HTML translator. Para isso tive primeiro que pensar num vocabulário, nos símbolos que representariam cada tag e que tags seriam permitidas. Acabei me baseando naquele que conhecia um pouco melhor, o sistema usado no projeto Trac, um gerenciador de projetos de software, aliás muito maneiro.

O sistema que desenvolvi tem recursos limitados em relação ao wiki format do Trac citado acima, mas é bastante funcional e, por ser em javascript, permite editar conteúdos no próprio navegador, vizualizar e modificar quantas vezes quiser antes de enviar ao servidor.

As razões para adotar o wiki format são muitas:

• A inserção de tags na página diretamente pelo visitante é um risco e deve ser evitado. Na medida em as tags inseridas são geradas automaticamente, esse risco desaparece.
• O risco de um desastre estético na sua página reduz consideravelmente.
• O wiki format, ao contrário dos editores WYSIWYG, força o usuário a criar um conteúdo semântico. O resultado pode ser um pouco mais pobre, mas estará 100% dentros dos padrões e com uma construção semanticamente correta.
• O usuário leigo pode aprender alguns símbolos simples bem mais facilmente do que compreender o HTML e seu funcionamento a ponto de usá-lo.
• Os editores de HTML online ainda deixam muito a desejar…

O wikitext.js também inclui um sisteminha bem legal para codificar a resposta de wiki2html() em ASCII e decodificar o ASCII na resposta de html2wiki(), se desejar. Além disso, há a opção de usar CSS para exibir o resultado de forma mais estética. Fiquei pensando em como fazer isso e achei que a forma mais fácil era simplesmente colocar o resultado HTML dentro de um div com um id definido (como "wiki"), dessa forma podemos formatar, por exemplo, todos os cabeçalhos criados (h1 a h4) com classes como as mostradas a seguir.

Veja aqui um aplicativo muito legal do Aurélio, o cara das expressões regulares: http://txt2tags.sourceforge.net/pt/. Este é um aplicativo em Python para gerar vários formatos a partir de textos wiki-formatados.

Abraços a todos, Cau Guanabara

Antes de tudo, lembro que já escrevi um post sobre como mesclar PHP com HTML que você deveria ler antes de começar.

A primeira coisa é lembrar que estamos falando de níveis diferentes. O PHP é interpretado no servidor e o JS no navegador. Ou seja, quando o javascript for executado, o PHP já terá cumprido o seu papel. Veja isso:

E é assim que o navegador vai fazer - quando o JS for interpretado, o PHP já não existirá no documento, restando apenas o resultado do seu processamento.

Imprimindo Javascript com PHP

Essa é a forma mais usada e acabamos de ver um exemplo dela no código mostrado acima. Basta escrever o código JS com as funções de impressão do PHP. Mas existe um formato que tem se popularizado bastante ultimamente e que facilita enormemente esse trabalho, o JSON (JavaScript Object Notation), com várias bibliotecas prontas para baixar. Aqui tem um script meu (muito simples, mas bem funcional) para traduzir PHP <-> JSON.

Resumidamente, o JSON é o seguinte…

Entendido isso, digamos que o JSON é simplesmente escrever arrays e objetos Javascript na sintaxe reduzida, mas trabalhar com essa construção na forma de string. Isso é utilizado para transporte de dados, num formato leve e muito prático - principalmente para a finalidade que daremos a ele nesse caso.

Vamos então abstrair (…) uma função tojson(), que representará a passagem de uma variável pela library escolhida, ok?

O resultado do exemplo acima, como será lido pelo browser:

Avariável userinfo é agora um object JS contendo os valores enviados pelo PHP. Como o formato JSON é baseado no (idêntico ao) formato da sintaxe reduzida do Javascript, não há nada mais a fazer, basta imprimir como veio - isso será um javascript válido.

Pontos de interseção entre PHP e JS

Apesar da diferença de níveis de execução, como já foi dito, há dois pontos que estão acessíveis tanto para o PHP quanto para o Javascript e que podem muito bem ser usados como forma de comunicação entre os dois.

O primeiro de que falarei é a QUERY STRING na URL do documento em questão. Para o PHP ela está disponível através da superglobal $_GET (ou $_REQUEST ou $HTTP_GET_VARS) e para o Javascript na URL, que pode ser conseguida em location.href. A diferença é que para o PHP as variáveis já vem tratadas, mas o Javascript só tem acesso à query string bruta, mas há meios de contornar isso. Veja aqui um post em que mostro como pegar essas variáveis com Javascript.

Isso significa que, se não carregarmos outra página, as variáveis GET que estiverem disponíveis no PHP também estarão para o Javascript depois de carregada a página no browser. Mas também poderíamos fazer algo assim:

A variável algo com o valor retornado pela função PHP peguealgoimportante() poderá ser lida pelo Javascript na página arq_do_js.html.

O segundo ponto são os COOKIES. São os mesmos para o PHP e o JS. O PHP oferece funções nativas para manipular cookies mas, prá variar, o JS não. Veja aqui algumas funções para manipular cookies em Javascript.

Podemos setar cookies com o PHP (setcookie() e setrawcookie()) e resgatá-los no navegador com o JS. Ou setar com Javascript e chamar um PHP, que poderá ler os cookies e trabalhar com eles, através da superglobal $_COOKIE (ou $_REQUEST).

Uma outra maneira…

O tipo de saída padrão do PHP é "text/html", mas podemos imprimir outros tipos de conteúdos, bastando setar o Content-type, com a função header. Isso significa que podemos gerar um conteúdo Javascript a partir de um arquivo PHP. É inusitado e extremamente útil.

Maneiro isso, não? mas não para por aí… olha o que podemos fazer:

ou assim… acho que fica mais fácil. Intercalar o JS com as TAGs PHP ao invés de usar funções de impressão é uma boa estratégia, pois evita a confusão que é imprimir aspas dentro de aspas. Outra é que podemos mudar a extensão do arquivo para .JS temporariamente e editar o JS com a sintaxe realçada no DW, por exemplo.

Isso funciona! podemos passar parâmetros por GET na URL do script PHP e como estamos usando o content-type = text/javascript, o browser não terá problemas em interpretar a resposta como JS.

Mas e para fazer isso sem recarregar a página?

Também é possível, mas só com ajax. Não é complicado, mas você deveria estudar um pouco sobre ajax antes de tentar esse método…

Essa aqui é a função mais simples possível para usar ajax:

usaríamos então dessa forma:

O que fosse impresso por meuphp.php seria recebido como texto na variável resp, no javascript.

Devem haver outras técnicas que desconheço… se você conhece, comente.

Abraço a todos, Cau Guanabara

Na época em que o Perl começou a ficar famoso era comum ouvir comentários por parte de programadores de outras linguagens sobre aquelas "linhas enigmáticas e indecifráveis do Perl", querendo se referir às tais ERs. Hoje as Expressões Regulares estão em todos os lugares. Se você está lendo este artigo, deve ser um desenvolvedor web, portanto usa ou já usou o famoso Dreamweaver. Pois bem, na janela de busca e substituição existe a opção "use regular expression" (minha versão é em inglês…), já reparou? e é uma mão-na-roda, pode crer. Nas linguagens então… praticamente todas tem suporte para ERs. Repare no exemplo abaixo:

Nosso exemplo não teria muita utilidade na prática, mas reparou que existem ERs nos três níveis (MySQL, PHP e Javascript)? pois é, é assim que eu penso ao programar. Às vezes até para transformar algum atributo de uma TAG ou mesmo criar e inserir novas TAGs no documento, eu prefiro o innerHTML, para manipular o texto com ERs, que o DOM (o que seria mais ‘natural’).

Já ouvi que sou maluco e que o método tradicional (strpos, substr, etc. (PHP) ou indexOf, etc. (JS)) é muito mais fácil. Desculpem mas eu discordo redondamente. Com ERs eu escrevo menos e e consigo resultados mais eficientes.

No meu tutorial há um capítulo onde falo do básico sobre ERs no PHP, dando destaque às funções compatíveis com o Perl [leia], mas o Aurélio, guru das expressões regulares, já tinha feito muito melhor. É dele o primeiro livro brasileiro sobre expressões regulares , disponível online também (o livro é muito legal, de fácil entendimento). Consulte o Aurélio para saber mais sobre como usar ERs.

As expressões regulares foram concebidas por dois neurologistas em 1943 num estudo sobre o funcionamento dos neurônios humanos que, anos mais tarde, foi retomado por um matemático que criou as notações, os símbolos para representar esses padrões - que só caíram nas graças da informática mais de 20 anos após sua concepção. O fato se deu em ambiente Linux, o que explica a relação com o Perl, nativo desse mesmo habitat. Tudo isso está dito no guia de consulta do Aurélio, já citado, mas repito aqui por achar, no mínimo, curiosa essa história.

Aprender ERs nunca será perda de tempo, pois há suporte amplo para elas na maior parte das linguagens e elas estão baseadas em conceitos sólidos - não vão mudar com a próxima versão de se-lá-o-que-for. Além disso, elas tornam seu programa mais inteligente, capaz de ler e modificar um texto de um modo mais semelhante ao modo humano.

É isso aí, foi apenas o desabafo de um programador que não se conforma com essa demora… por quê elas não são mais populares ?!?

Para terminar, vou repetir: não sei programar sem ERs.

As funções print() e echo()

Servem basicamente para a mesma coisa, com algumas diferenças…

• echo é capaz de receber mais de um parâmetro, mostrando a concatenação dos mesmos.
• echo tem uma forma abreviada para usar dentro do HTML (<?="abc"?>) .
• print oferece o modo "heredoc" que permite misturar HTML, variáveis e aspas indistintamente, mas é bem pouco usado.
• print retorna o valor mostrado. $str = print "teste"; -> imprime e coloca em $str o valor "teste". echo não retorna nada.
• Ambos são construções da linguagem, portanto podem ser chamados com ou sem os parênteses, mas para enviar mais de um parâmetro para echo, o uso de parênteses é problemático.
• Veja uma explicação das diferenças entre print e echo (em inglês).

O uso das aspas simples e duplas

A escolha do tipo de aspas usado com as funções de impressão (print e echo) é fundamental, pois o resultado pode ser bastante diferente.
Com aspas duplas (") podemos usar variáveis e caracteres especiais, como ‘\n’ (para criar uma quebra de linha), já entre aspas simples tudo é literalmente impresso. Veja:

Para imprimir aspas dentro de aspas

Entre aspas simples podemos usar aspas duplas à vontade - e vice versa. Para usar duplas dentro de duplas ou simples dentro de simples, é preciso ‘escapá-las’ com uma contra-barra (\’ ou \") . Veja aqui.

Misturando strings e variáveis

Com as aspas duplas, já vimos que podemos mesclar diretamente, sem concatenação, mas isso deixa de ser verdadeiro para variáveis complexas como elementos de arrays multidimensionais ou propriedades de objetos.

Com isso podemos evitar muitas concatenações desnecessárias e chatinhas de escrever, poupando tempo no ato de programar. A sintaxe complexa também vale para o modo heredoc, com print().

Mesclar PHP e HTML

Até aqui falamos de PHP, mas como a interface com o usuário é, em quase todos os casos, em HTML, estamos o tempo todo combinando os dois. Qual é a melhor maneira de fazer isso? Bem, a primeira coisa a lembrar é que PHP e HTML são interpretados em níveis diferentes: o PHP no servidor, antes do envio da resposta HTML, que será interpretada (com seus Javascripts, CSS, etc…) pelo browser. Isso equivale a dizer que podemos escrever livermente o HTML/JS/CSS/etc. com PHP, pois quando estes forem renderizados/executados pelo navegador, o PHP já terá cumprido o seu papel e de tudo que estava entre TAGs PHP só restará o que foi impresso.

Veja algumas formas possíveis:

Mostramos acima uma forma de mostrar conteúdos sem usar nenhuma função de impressão, a interpolação entre PHP e HTML. Ao passo que encapsulamos a abertura do if em uma TAG PHP e seu fechamento em outra, podemos trabalhar com HTML puro dentro do escopo desse if e esse conteúdo é suprimido se a condição for falsa, mas…

Se queremos, por exemplo, criar uma sequência de links e fazemos uma função para isso, a princípio não podemos usar a interpolação simples, pois isso manda diretamente para a tela. A não ser que usemos as…

Funções de controle de fluxo

Com as funções ob_* do PHP é possível trabalhar com o HTML puro sem enviar diretamente para a tela. Podemos capturar a saída HTML para uma variável. Veja:

A função acima normalmente seria algo assim:

Eu acho mais vantagem a interpolação por poder editar o HTML num editor no modo visual, sem precisar criar trechos complexos de HTML na munheca. Bem, acho que é isso.

Era uma diversão misturar e tentar atingir a cor que eu queria. Consultava uma tabela de cores, via a porcentagem de cada uma das primárias e transportava isso para meus potes de tinta - quase sempre era preciso acrescentar uma pitada de branco ou preto. Esse método me dava uma nova tinta, uma cor "chapada", por isso a necessidade do branco de vez em quando… mas o sistema usado nas gráficas para imprimir separa as três cores primárias e acrescenta uma camada corretiva de preto, imprimindo uma sobre a outra separadamente (o branco é o papel no fundo). É o sistema CMYK (Cian, Magenta, Yellow e blacK). A teoria é que a soma C+M+Y, os três a 100%, seria igual a preto - mas na prática isso não se mostra verdadeiro, por isso a camada K foi adicionada.

Até aqui falamos de cor-pigmento, ou seja a cor de uma determinada superfície, que depende da luz branca para aparecer. A idéia é que uma superfície colorida ao receber a luz branca, reflete o seu tom, "absorvendo" as outras tonalidades do espectro, mas existe outro tipo de cor: a cor-luz.

Esta é como é, não depende de ser iluminada para ser vista. Os tons do pôr-do-Sol, por exemplo, ou as cores que você vê no seu monitor. Pois é, o monitor trabalha com cor-luz e aqui a teoria é bem diferente. Trabalhar com cores-luz significa usar o sistema RGB - Red, Green e Blue (vermelho, verde e azul), um outro sistema, que inversamente ao anterior, determina que a soma das primárias R+G+B a 100% é igual a branco! O preto aqui se manifesta pela ausência de luz. Esse é o sistema com que vamos trabalhar: RGB e para expressar uma cor RGB em documentos HTML usamos normalmente o modo hexadecimal ou, para o CSS, podemos também definir uma cor diretamente em RGB. Vamos inicialmente entender o RGB, depois o hexadecimal.

Para formar determinada cor, trabalhamos com 3 "canais de cor", R, G e B. Ao alterar a porcentagem de cada canal de cor, alteramos o resultado final da cor exibida. Como foi dito, R+G+B a 100% = branco, portanto, R+G+B a 0% = preto.
Bem, os valores numéricos para cada canal vão de zero (0%) a 255 (100%), portanto os exemplos acima seriam (para CSS) escritos assim:

• preto: "rgb(0,0,0)"
• branco: "rgb(255,255,255)"

A partir daí podemos, por dedução simples, perceber que para representar as primárias "puras", bastaria partir do preto, adicionando apenas um canal a 100%:

• vermelho (R): "rgb(255,0,0)"
• verde (G): "rgb(0,255,0)"
• azul (B): "rgb(0,0,255)";

Se usarmos o método "inverso", partindo do branco e subtraindo apenas um dos canais, chegamos às cores CMY do sistema CMYK:

• ciano (C): "rgb(0,255,255)"
• magenta (M): "rgb(255,0,255)"
• amarelo (Y): "rgb(255,255,0)"

Outra é que sempre que todos os canais tiverem o mesmo valor (como no branco e no preto), estaremos falando de tons de cinza. Se imaginarmos um gráfico para representar os três canais, entenderemos que a cor surge da curva, enquanto a reta é cinza. Apenas para dar uma idéia mais clara sobre o que estou falando:

Já ficou mais fácil entender como funciona a coisa, não? Agora é só começar a usar valores intermediários para se conseguir as outras cores. Não é muito diferente de misturar tintas… Ok, vamos agora entender o sistema hexadecimal, que será apenas uma outra forma de escrever uma cor RGB, dividida por canais, só que com os valores representados de forma hexadecimal.

Não vou entrar em detalhes sobre o sistema hexadecimal mas vamos ver como traduzir um valor decimal para hexadecimal usando Javascript. Num post recente, mostro funções para converter rgb <-> hexadecimal, aqui vou mostrar apenas o cerne da coisa.

Os valores hexadecimais são 16: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E e F. As letras foram usadas para representar números de dois dígitos com apenas um caracter.
Veja: A = 10, B = 11, C = 12 , …, F = 15.

O sistema hexadecimal é largamente utilizado em computação (não apenas nas cores) por representar uma economia considerável de de memória e de processamento. Veja o que achei na wikipedia (…/wiki/Sistema_hexadecimal):

O sistema matemático de conversão para hexadecimal não é algo tão complicado… Veja neste comentário ou nesta página mais completa.

O formulário abaixo usa Javascript para traduzir um valor RGB (0-255) decimal para hexadecimal. Tudo acontece no evento onsubmit do form (veja o código abaixo).

Tradutor RGB <=> hexadecimal

Retirando-se o "#" , os seis caracteres restantes representam os 3 canais RGB, nessa sequência, dois a dois. Por ex. em "#66AAFF" o canal R está representado por "66", o G por "AA" e o B por "FF". Se você clicou no botão acima, já viu que 255 em hex. é igual a "FF". Então já podemos deduzir que "#FFFFFF" é o mesmo que "rgb(255,255,255)" (branco) e que "rgb(0,0,0)" é igual a "#000000" (preto). Como seriam então as primárias em hexadecimal?

• vermelho (R): "#FF0000"
• verde (G): "#00FF00"
• azul (B): "#0000FF"

ou, para as primárias do sistema CMYK:

• ciano (C): "#00FFFF"
• magenta (M): "#FF00FF"
• amarelo (Y): "#FFFF00"

Como em RGB, agora basta usar tons maiores que "00" e menores que "FF" para obter qualquer outra cor. aqui está uma ferramenta legal para botar em prática o que foi dito aqui.

No mais, bom carnaval 2007!!!!

Isso é verdade, mas uma verdade relativa… a princípio, o Javascript não pode mesmo fazer isso, mas pode ler a URL completa do documento atual.

Tá mas e daí?
Para quem fez essa pergunta, vou primeiro explicar que, como quem quer aprender Javascript já deveria saber, existem dois métodos básicos para enviar dados ao servidor:

• POST
  Usando POST, os dados vão embutidos nos headers (cabeçalhos) HTTP que são trocados entre o servidor e o navegador web (escondido do usuário).
• GET
  Por GET os dados são enviados como parte da URL, após o sinal ‘?’.

Se podemos ler a URL então temos acesso aos dados enviados por GET, bastando tratá-los para poder ler e usar. Vamos dar um exemplo prático, começando pelo envio dos dados.

Podemos simplesmente criar um formulário e definir o atributo "method" para "get", assim:

Mas podemos também criar a query string manualmente. Há três funções em Javascript para codificar esses dados:

• escape -> desatualizada. Codifica os dados em hexadecimal
• encodeURIComponent -> codifica uma string para ser enviada (UTF-8)
• encodeURI -> codifica uma URI inteira para ser enviada (UTF-8)

Supondo que os dados são do "joão", com o email "jo@o.com". Nesse caso, o valor enviado pelo formulário seria uma string (iniciada por "?" e seguida por pares nome-valor, unindo o nome ao valor por "=" e um par ao outro por "&") colocada ao final da URI definida na propriedade action do formulário, resultando em algo assim:

file.html?nome=jo%E3o&email=jo@o.com

Mas e se quisermos criar um link dinamicamente?

Repare que o resultado do script acima é ligeiramente diferente do anterior (formulário):

file.html?nome=jo%C3%A3o&email=jo%40o.com

Isso ocorre por quê o método nativo utilizado ao submeter um formulário codifica em ASCII hexadecimal e o script acima resulta numa string codificada em UTF-8, que é mais universal. Bem, ok. Os dados foram enviados… vamos recebê-los!

Vamos construir uma função que lê a URI e retorna os pares nome/valor encontrados, na forma de um objeto. A função está toda comentada. Lá vai…

Importante ressaltar que, no caso de haver múltiplos inputs com o mesmo nome, apenas o último irá valer.

Veja aqui um script mais complexo para gerar e receber variáveis GET. Neste há suporte para o método utilizado pelo PHP para trabalhar com grupos de checkboxes (normalmente), onde basta acrescentar ‘[]’ ao nome que será repetido nos inputs, que o sistema receberá esses dados como um array contendo todos os valores dos campos de mesmo nome, terminados por ‘[]’ .

Basta agora atribuir o resultado da função a uma variável, assim:

Como a URL da página está disponível desde o primeiro momento, não é preciso usar o evento onload. Podemos simplesmente executar antes da página carregar.

É isso aí e bom carnaval!!!

Minha situação era a seguinte: eu precisava marcar, sobressaltar partes de um texto, mas não sabia qual seria a cor desse texto. Bem, para isso existe o valor ‘highlight’, mas ele não é aconselhado pela W3C… e nem sempre o resultado é ir para a cor oposta a do texto, embora resolva os problemas de baixo contraste. Mas o W3C falou, tá falado. Usei, a princípio, cores fixas (fundo azul marinho e fonte branca). Não ficava mal, mas seria mais elegante usar a cor oposta… e fiquei com isso na cabeça: como inverter uma cor?

Bem, tanto o sistema hexadecimal quanto o rgb trabalham com as cores básicas - vermelho, verde e azul - com um valor mínimo (hex:00, rgb:0) e um máximo (hex:FF, rgb:255) para cada uma. Tendo o início e o final do ‘espectro’, poderíamos subtrair o valor enviado do valor máximo, obtendo um valor ‘oposto’… naturalmente, optamos por usar o sistema RGB, que trabalha apenas com valores numéricos (0-255).

A primeira coisa que precisava eram funções para traduzir rgb para hexadecimal e vice-versa. Achei aqui umas funções que usei a um tempo atrás, provavelmente retiradas do HTMLArea (atual Xinha), para o qual construí alguns plugins. Lá vão elas:

Agora basta fazer a função para inverter. Trata-se de uma ação simples, mas a função acabou ficando grande pois trabalha com valores em Hex e RGB, retornando um tipo semelhante ao que foi enviado, mas sempre na forma de uma string.

O valor enviado à função invertColor pode ser como os exemplos a seguir:

• invertColor("#CC0000") -> retornaria algo como "#0000CC"
• invertColor("FFFF00") -> retornaria algo como "#0000FF"
• invertColor("#FF0") -> retornaria algo como "#0000FF"
• invertColor("FF0") -> retornaria algo como "#0000FF"
• invertColor(120, 120, 0) -> retornaria algo como "rgb(135, 135, 255)"
• invertColor("rgb(120, 120, 0)") -> retornaria algo como "rgb(135, 135, 255)"

Lá vai a função:

Segue um exemplo para testar a função:

É isso aí. Espero que seja útil para você.

Desde que comecei a blogar (já descobri que trata-se de um vício), tinha vontade de mostrar links para os últimos posts do blog no meu site. Procurei no forum do blogsome e pela rede, mas não achei nada interessante (sei que deve haver algo). Enfim, resolvi fazer meu próprio script, mas como acessar os dados num banco de dados que não me dá acesso? Quando achei a solução me senti até um pouco burro. Claro, os feeds RSS. Lá está o conteúdo que eu queria e bem acessível (sem comentários). Vamos por partes, como faria Jack.

O script deve mostrar uma relação de links como no próprio blog, mas há certas funcionalidades no blog que devem ser reproduzidas aqui:

• Definir um tamanho máximo para o título, sem dividir palavras.
• Definir um número máximo de links na lista.
• Definir se o link abre na mesma ou em outra janela.
• Poder apresentar essa lista de links de várias formas.
• Poder definir a codificação do resultado (ISO, UTF, etc.).
• Poder usar em qualquer blog WordPress (e outros?)

Tudo isso vai ser definido através de valores enviados via POST/GET (para usar com ajax) ou em variáveis declaradas antes de incluir o arquivo (para sistemas em PHP). No trecho abaixo vamos procurar por esses valores nos dois caminhos citados acima: em variáveis nomeadas e em $_REQUEST (POST + GET + COOKIE):

O sistema vai trabalhar com o feed, portanto precisamos transformar a URL do blog de forma que aponte para o XML que contém o RSS. No WordPress, basta acrescentar a string ‘/feed/’ no final da URL. ‘http://seublog.wordpress.com’ vira ‘http://seublog.wordpress.com/feed/’ e pronto, temos todo o conteúdo em RSS.
Talvez esse sistema possa ser usado com outros servidores de weblogs apenas mudando o trecho abaixo…

Faremos agora uma funçãozinha para reduzir os títulos dos posts, como acontece no WordPress, para manter um padrão de tamanho na lista de links. O caso é que não basta usar substr(). Não queremos cortar palavras….

Precisamos agora de um sisteminha para ler o conteúdo que está em um arquivo XML e interpretá-lo. Essa será a função principal e já temos tudo que iremos precisar para que ela funcione.

Sempre que preciso ler um XML acabo baixando um script pronto e usando sem entender direito como ele trabalha… mas dessa vez fiz diferente. Incrível a economia de código que esse pequeno esforço proporcionou. Bem, segue a função, toda comentada:

Restou apenas executar isso tudo. É, essa função não vai ser chamada de algum lugar, o script deve se executar ao ser incluído ou chamado via XMLHttpRequest.

Agora basta juntar isso tudo e está feito! eu chamei de wp-posts.php, mas você pode chamá-lo como quiser.

Veja dois exemplos de como usar o sistema:

Até pouco tempo atrás, eu mesmo nunca tinha pensado a respeito, mas agora parei para fazer isso e percebi o quanto é importante - além de ser respeitoso e educado com aqueles que tem alguma dificuldade e que tem (ao menos teoricamente) o direito de acesso a tudo que é público. Mas como traduzir esses conceitos de acessibilidade para um website?

Bem, no site do SERPRO há alguma informação, uma matéria bem legal no imasters e muita coisa disponível na rede. Se fizer uma busca em inglês então, é uma festa e a razão é simples: estamos falando de um dos pilares do movimento denominado ‘web 2.0′. Mas, apesar de todos já sabermos disso, há muito poucos sites totalmente acessíveis na web.

O que é importante para um website ser acessível?

Um site acessível é aquele que pode ser utilizado nas mais diversas situações e apresenta certas características especiais. Apresento abaixo uma lista dos itens considerados importantes

1. imagens, gráficos, audio e vídeo devem ter descrições alternativas
2. o texto deve ter contraste com o fundo e poder ser ampliado
3. deve poder ser visto e entendido sem as imagens
4. links e elementos de formulário devem estar dispostos com lógica
5. deve poder ser visto e entendido sem o CSS
6. o conteúdo de tabelas deve fazer sentido lido linha a linha
7. deve poder ser usado sem javascript

Bem, algumas das regras acima são fáceis e não são usadas apenas por simples desconhecimento, acredito. Outras nem tanto… vamos uma a uma.

Imagens, gráficos, audio e vídeo devem ter descrições alternativas

Fácil. Basta não esquecer de preencher o atributo ‘alt’ nas imagens e ter legendas para os vídeos e audios (como um link ao lado, que leva a um texto descritivo). As imagens e a nescessidade do alt são muito faladas e todos já sabemos, só não sabíamos que o motivo é a acessibilidade. Pois é, o alt não serve apenas para os casos em que as imagens não carregam, mas também para os que não podem vê-las.

Com o advento do atributo ‘title’, restou uma certa confusão quanto à tag img. ALT ou TITLE - qual usar? pra que serve cada um? Bem, o ‘title’ nas imagens tem a mesma finalidade que em qualquer outra tag: exibir um texto descritivo. Já o ‘alt’ está associado à acessibilidade. Se ambos existirem, ao parar o mouse sobre a imagem o ‘title’ aparece, mas se a imagem não puder ser exibida, o ‘alt’ é que será mostrado.

O texto deve ter contraste com o fundo e poder ser ampliado

O contraste é uma exigência para satisfazer aos portadores de daltonismo, que tem dificuldade para reconhecer as cores, especialmente as combinações de cores opostas verde-vermelho e azul-amarelo.

Quanto a poder ser ampliado, estamos falando do tipo de medida escolhido para as fontes na página. Como sabemos, o usuário pode ampliar ou reduzir o tamanho do texto exibido na página, para os casos de miopia ou outra deficiência visual parcial - a menos que na folha de estilos do site o tamanho das fontes esteja definido em medidas absolutas, como pixels, pontos ou milímetros, por exemplo. A medida em pixels, na verdade é classificada como relativa, mas a sua relatividade se refere à definição de vídeo, não ao tamanho de fonte herdado - por isso, para a nossa finalidade, não funciona.

A solução é se basear na folha de estilos do navegador, usando as medidas relativas porcentagem, em e ex. Esses três medidas trabalham em cima do tamanho herdado de fonte - e poderão ser modificados se o usuário precisar.

O site deve poder ser visto e entendido sem as imagens

Muitos usuários com deficiência visual usam browsers que lêem apenas o texto ou outros dispositivos que ignoram as imagens, por isso nunca escreva nas imagens - escreva em texto - e se precisar fazer isso, capriche na descrição.

No caso de estar usando um sistema anti spam tipo captcha ("digite aqui a palavra que você vê na imagem ao lado…"), onde não se pode usar o atributo alt ou title, não esqueça de disponibilizar a mesma palavra em forma de áudio, para deficientes visuais.

Os links e elementos de formulário devem estar dispostos com lógica

Há pessoas que por algum motivo não podem usar o mouse e vão navegar pelo seu site através do teclado. Aqui nos deparamos com a necessidade da semântica correta. Espera-se que os itens clicáveis da sua interface sejam apenas links ou elementos de formulário, que são acessíveis com o uso de Tab, Shift + Tab e Enter.

Se por algum motivo a disposição dos links em seu HTML - na ordem em que foram escritos, não na ordem em que aparecem na página - não seguirem uma seqüência lógica, use o atributo ‘tabindex’ para definir a ordem de acesso.

O site deve poder ser visto e entendido sem o CSS

Pelo mesmo motivo citado no item acima, em certos casos o CSS é dispensável, então, simplesmente não é renderizado. Sabemos que a seqüência em que os elementos são escritos no documento HTML pode não ter nada a ver com a forma que são exibidos, com layers e floats e tudo mais que o CSS oferece. Apesar disso, é preciso que o texto tenha sentido na seqüência mesma em que aparece no HTML, pois esses dispositivos lêem apenas o texto em sua ordem original.

O conteúdo das tabelas deve fazer sentido lido linha a linha

No tipo de leitura citado acima (do documento HTML e não da tela), as tabelas serão lidas como estão escritas, uma TD depois da outra formando uma linha e uma TR depois da outra. Ou seja, os dados serão lidos da esquerda para a direita, TD por TD e de cima para baixo, TR por TR. Portanto se o conteúdo dessa tabela só faz sentido quando interpretado em colunas, ele aparecerá ‘truncado’, misturado e impossível de ser compreendido.

O site deve poder ser usado sem javascript

O Javascript, mais que o CSS, é passível de ser desabilitado. Muita gente faz isso por simples questões de segurança. Outros pelos mesmos motivos dos itens acima. Aqui chegamos a um tema ainda pouco comentado mas de vital importância: Javascript não-obstrutivo. O que é isso?

É simples de entender: sua forma de usar o Javascript não deve impedir a página de funcionar caso o mesmo esteja desligado. Por exemplo, sabemos que para estarmos semanticamente corretos, devemos construir nossos menus com elementos <A>, mas um link assim não serve pra nada sem o Javascript:

Já este pode ser usado também sem ele:

No segundo exemplo, executamos a função e desabilitamos o href com a expressão ‘return false;’. Caso não haja JS, o link e irá funcionar normalmente. Outra situação é quando, através do menu de contexto, usamos a opção ‘Copiar link’ ou ‘Copiar atalho’. No exemplo acima, enviaríamos para a área de transferência a string ‘javascript://’, que de nada serviria. O mesmo se aplica para o comando de abrir o link em uma nova janela.

Quando seu javascript for responsável por mostrar alguma informação relevante, use a tag noscript para explicar o conteúdo que não pôde ser exibido. Aqui nos deparamos com um problema: noscript costuma causar problemas de validação como XHTML 1.0 e precisamos decidir o que é mais importante, validar ou dar acesso.

Se há áreas que só aparecem via javascript, com mudanças dinâmicas no CSS, crie essas áreas visíveis e as esconda no onload da página. Assim, se não houver Javascript, elas estarão visíveis (e acessíveis).

O tão utilizado ‘menu de salto’ (um select com função definida no evento onchange) é também um obstáculo para quem navega pelo teclado, pois ao mudar o campo, o onchange é acionado e o usuário que não conhece o uso da combinação Alt + seta para abrir o menu, nunca passará do primeiro item - e a grande maioria não conhece.

Enfim, a falta do Javascript não pode inviabilizar a navegação. Leia essa matéria já indicada acima, é uma verdadeira aula sobre non-obtrusive javascript, dividida em 5 episódios: http://www.imasters.com.br/artigo/4298/javascript/tudo_sobre_javascript_nao-obstrutivo_-_parte_01/

Outras…

Fora isso tudo, não esqueça de declarar o idioma em que o conteúdo está escrito, com o atributo lang na tag

Todas as regras de usabilidade também são aplicáveis e importantes aqui, como:

• O menu principal deve estar acessível de qualquer lugar do site
• Um retorno para a página principal sempre visível
• Abrir conteúdos externos ao site em novas janelas
• Oferecer um mapa do site com links diretos
• Usar textos descritivos nos links, com title
• etc, etc e etc…

Validação

Existem serviços online para validar a acessibilidade de um website, inclusive um em português, o DaSilva. Veja também o WebXACTe outros aqui. Mas já vou avisando: validar totalmente um site é quase impossível quando se usa muito JS/DOM/CSS, mas dá dicas interessantes quanto às nossas faltas.

Acessibilidade é uma questão de respeito pelo próximo

… além de ser uma exigência do novo modelo de internet - aliás, do novo modelo de mundo.

Web 2.0 sem acessibilidade não rola. Da mesma forma que um supermercado não pode deixar de ter rampas de acesso, o conteúdo de um website não pode estar acessível apenas para um grupo, mesmo que este represente a maioria.

Além disso, tem gente apostando que a acessibilidade é uma grande oportunidade de negócio, veja por quê .

O HTML nos oferece uma forma nativa de fazer isso: a propriedade accesskey. Originalmente aplicável em a, area, button, input, label, legend e textarea, depois foi liberado para todos os elementos renderizáveis. Usa-se então uma tecla (definida em accesskey) combinada com [Alt] ou [Ctrl], dependendo do browser, para mover o foco para o elemento, mas não funciona a contento. Depois, queremos executar comendos Javascript e não apenas mover o foco.

Construí então um sisteminha para capturar e reconhecer esses eventos, transformando-os em strings facilmente interpretáveis, como “CTRL+Q” ou “SHIFT+CTRL+B”. Acabei por fazer uma função que retorna um objeto contendo quatro informações: a string em si, o número da tecla pressionada e dois valores boleanos para saber se as teclas [Ctrl] e [Shift] estão pressionadas. O usuário deve então criar uma função para receber e interpretar esse objeto, executando as ações relacionadas. Vamos ao código.

Começamos criando duas variáveis: isIE, que diz se estamos no IE, e hotKeysOk, que é inicializada com o valor false e irá nos dizer se há uma função definida para executar os comandos.

Bem, vamos então à função getHotKeys. É ela que detecta a ação de pressionar uma ou mais teclas e lê a combinação, transformando em texto e executando a função do usuário - que veremos adiante. Ao executar a função do usuário, enviará como parâmetro um objeto com a seguinte estrutura:

A função em si:

Ok, a função está toda comentada, mas e a execHotKeys? cadê?
Pois é, a função abaixo foi o meu modo de resolver isso. Crio a execHotKeys on-the-fly, a partir de uma função enviada como parâmetro à setHotKeysFunction. Ao fazer isso, podemos setar hotKeysOk para true. A função de interpretação já existe e a getHotKeys já sabe o seu nome: execHotKeys.

Só faltou agora a função para interpretar os comandos de teclado e executá-los, a mesma recebida como parâmetro na função aí em cima. Essa funçãodeve estar pronta para receber e interpretar o objeto recebido. No nosso exemplo, ela apenas dá um alert mostrando os dados do objeto, mas podemos criar várias estratégias para reconhecer os comandos a partir dessas informações enviadas à função.
Esta é a função que está funcionando na página de exemplo:

Mas poderíamos fazer algo como isso:

Tudo bem, mas e para fazer isso funcionar?
Basta adicionar as duas linhas abaixo, definindo comportamentos para dois eventos na nossa janela: ao carregar a página (window.onload) definimos a nossa função myHotKeys (que irá executar os comandos) com setHotKeysFunction e ao pressionar uma tecla (document.onkeypress), chamamos a getHotKey que fará o resto do trabalho.

Atenção, a propriedade str no objeto enviado à sua função irá retratar a combinação de teclas como mostrado abaixo.

• A letras sempre são mostradas em maiúsculas, o que diferencia das minúsculas é a presença do SHIFT.
• Os caracteres não alfabéticos suprimem a substring SHIFT+ da string de retorno, mostrando apenas o próprio caracter
• Caracteres não alfabéticos não funcionam em combinação com Ctrl.
• Caracteres acentuados, como “Ç”, não são aceitos.
• As combinações que correspondem a atalhos do navegador, como Ctrl + A devem ser evitadas. O que acontece:
  • no IE são desabilitados
  • na família Mozilla não impedem a execução da funcionalidade correspondente - as duas coisas acontecem

Tabela com alguns exemplos:

Veja aqui uma página de exemplo

É isso aí, abraço, Cau.

Nunca quis ter um site pessoal, mas acabava sempre fazendo "algo" e colocando no ar. Nunca eram muito visitados (graças a Deus) e, invariavelmente, eu os odiava na semana seguinte. Dessa vez acho que vai ser diferente, pois não estou pensando em um site apenas profissional, mas em um espaço para divulgar minhas idéias e tudo mais que me der na telha.

No site …

… dá pra ter uma idéia da minha história e do meu trabalho, pra entrar em contato comigo, etc., mas o mais importante é um tutorial de PHP 4 que disponibilizei para consultas. Essa apostila foi criada para um curso que nunca se realizou, inclusive já publiquei no blog um capítulo dela. Prometo mudar a formatação para algo mais a ver com o site.

Além disso, em breve haverá um "Guestbook", um modo para quem chegar poder deixar um comentário, enquanto isso, o blog é o local.

É isso aí. Abraço, Cau

Esse script foi criado a partir de um exemplo que consegui na internet há anos, não sei, mas se não me engano foi num site da Microsoft. Não havia informações autorais, mas a verdade é que quando digo "criado a partir de" significa que mudei bem a coisa.
O legal da função é que usa propriedades e métodos nativos do elemento <table> e de seus sub elementos, que quase não se vê e não são muito utilizados - coisa antiga, da época em que "Dom" era só para quem tinha algum talento especial e "Ajax" não passava de material de limpeza (rsrsrs).

Pois é, mas voltando ao presente, a semântica nos diz que as tabelas não são para criar estruturas de design, como se usava, mas para exibir dados "tabulares", aqueles que estamos acostumados a ver em forma de "planilhas", no Exel por exemplo. E junto com essa idéia, funções específicas foram criadas para que os dados exibidos tivessem alguma mobilidade. Propriedades como Table.rows, Table.cols, Table.tbody, Table.tBodies… quem usa isso? Bem, eu não. Mas adorei conhecê-las.

A função sortTable() deve ser definida como uma propriedade do(s) elemento(s) <table> em questão, dessa forma todos os dados estarão acessíveis, pois serão membros do mesmo objeto - isso deve acontecer no onload ou num script colocado abaixo do elemento, quando a tabela já existe efetivamente. Um detalhe importante é que precisaremos do também quase esquecido elemento <tbody>, que também possui a propriedade rows. Isso por quê dessa forma delimitamos o conteúdo a ser classificado, excluindo os cabeçalhos das colunas - senão ao clicar, o <th> - que também é incluído no objeto rows, entra na dança e pode ir para em qualquer linha, de acordo com seu texto.
A função lê o conteúdo do primeiro tbody da tabela - digo isso por que é lícito usar mais de um tbody em uma mesma tabela. Não iria funcionar direito.

Fazemos um loop pelas rows da tabela, colocando-os em um array, na mesma seqüência. Aí está o "segredo" da classificação: basta usar os métodos sort() e reverse() do objeto Array. Depois de rearrumar o array, refazemos a tabela a partir dele. Veremos que há duas funções necessárias para que sortTable funcione: generateCompareTRs - usada como parâmetro para o método Array.sort - e getColValue, que só aparecerá mais adiante. Veja a função principal:

A função generateCompareTRs() recebe o índice da coluna que servirá como base para a classificação e retorna uma outra função que será enviada para o método sort. Ela determina, segundo os valores a serem comparados, se a comparação será numérica ou baseada em strings e a função retornada será apropriada para os valores da coluna em questão.

Além dela há também a função getColValue(), que recebe um elemento <td> e busca por um conteúdo classificável. Veja a ordem de precedência no retorno da função:

• se há apenas texto, retorna o texto
• se há texto e TAGs, retorna apenas o texto
• se não há texto:
  • se há (na TD) o atributo "title", retorna seu valor
  • se o 1º elemento da TD é uma IMG:
    • se há o atributo "title", retorna seu valor
    • se há o atributo "alt", retorna seu valor
    • se não há alt nem title, retorna o atributo "src" da imagem
• se não é nenhum dos casos acima, retorna uma string vazia

Vejamos a getColValue():

Claro que se poderia fazer o mesmo usando apenas o DOM, mas é mais simples assim e estamos falando de IE 4 e NS 6 - praticamente não há falta de suporte dos navegadores. Contradizendo isso, a função generateCompareTRs usa o método localeCompare, da versão 5.6 do Javascript…

Independente de preferências, considero a função bastante útil e espero que seja de ajuda para alguém.

Veja aqui uma página de testes

Bem, já que ninguém se manifesta, vamos nós ao BadgerFish, concebido por David Sklar.
Segue uma tradução (de partes) da página original:

Além do mostrado acima, a página oferece um script em PHP para tradizir, feito pelo próprio David Sklar (que depende do Services JSON, da Pear) e algumas outras referências.

Para dar um exemplo inicial, considere o trecho de XML abaixo:

Cada elemento vira um objeto (regra 1, bem mal traduzida…) e é colocado como uma propriedade do objeto relativo ao seu elemento pai, a não ser no caso do elemento root, que é ‘o pai de todos’. A regra nº 2 (o texto de um elemento vira a propriedade “$” do objeto correspondente) também está em ação.

Veja o resultado:

O JSON em si é a string que está sendo atribuída a json_str. Criaremos a json_obj para receber a string ‘parseada’, assim:

Assim, bastaria atribuir o objeto (transformado de string para objeto) a uma variável (json_obj) e para pegar o texto do elemento <name> usaríamos:

Sim, mas e se fosse um arquivo XML completo? Veja:

Esse arquivo depois de ‘traduzido’ pelas normas do BadgerFish, seria uma string JSON assim (as quebras de linha não são necessárias… apenas para ilustrar):

Mas como ficaria se houvesse duas TAGs <item> na TAG root?

Como há duas TAGs iguais em seqüência e no mesmo nível, aplicamos a regra nº 4, transformando a seqüência em um array. Não poderíamos criar propriedades com o mesmo nome em um mesmo nível de um objeto JS - então fica assim:

E se os elementos tivessem propriedades e não apenas sub elementos? Aí se aplicam as regras n^os 6, 7, 8 e 9 . Considere esse outro XML:

A nona e última regra “Elementos com prefixo de namespace tornam-se também propriedades do objeto“, traduzindo a minha tradução, significa que todos os elementos contidos em um elemento com um ou mais namespaces definidos devem também ter esse(s) namespace(s) como propriedades.
Eu considero um certo exagero, posto que o princípio da hereditariedade usado no próprio XML é aplicável aqui também. Mais embaixo (O que falta fazer, 3), o próprio David sugere ignorar inteiramente os namespaces… esse tem aplicação possível - nem sempre estamos interessados nos namespaces…

Resolvi usar a hereditariedade, declarando o namespace apenas no objeto reletivo ao elemento em que o tal namespace foi declarado.

Veja o resultado:

Transcrevo abaixo o mesmo arquivo traduzido segundo a nona regra, literalmente (traduzido pelo script do David):

Não vou julgar, pois esse é um tópico que me parece óbvio demais… provavelmente há algo que eu não percebi, não sei. Por quê declarar em todos os sub elementos? Bem, finalizando…

Fiz um script (qualquer hora mostro aqui) para fazer essa tradução, mas na hora da prática percebi alguns problemas… segue um trecho do texto que adicionei ao dito script:

Entrei em contato com o David Sklar a respeito das dúvidas colocadas acima, mas ele repondeu sem muito interesse, me deixando livre para criar minhas próprias regras complementares. Bem, foi o que fiz. Deixo isso claro, por que, se alguém achar que pode melhorar, por favor melhore!

Abraço, Cau Guanabara

A idéia surgiu  com uma função que encontrei nos meus garimpos, para determinar a posição exata de um elemento na página, a absPos(). Essa é uma função que está toda dentro de um for que não tem bloco de comandos, numa sintaxe legal, pouco comum. Não sei quem é o autor (displicência minha… desculpe-me por isso o autor dessa função tão legal), veja:

Bem, sabendo a posição e as dimensões do elemento, bastava pegar o innerHTML, jogar em um input e colocar em cima do elemento editado. A função ficou curta e eficiente, restando o problema visual de, ao editar textos formatados, não exibir a mesma formatação do texto original. Um elemento pode ser herdeiro de uma grande quantidade de regras CSS e não consegui um meio de fazer o meu input herdar isso também.

A editInPlace depende de duas outras funções: absPos() e uma versão minha da função $ do prototype, que pega ou cria um elemento com determinado ID.

Lá vão as funções:

Segue um exemplo de uso, supondo que o conteúdo acima está no arquivo editinplace.js:

Resolvi inserir o texto ‘[vazio]’ quando o usuário deleta o texto, pois não dava para criar algo clicável sem texto…
Bem, vou ficando por aqui. Sei que fui muito sintético, mas estamos aí… comente, pergunte que eu explico.

Abraço, Cau Guanabara.

Todo aplicativo se destina a automatizar um processo que poderia ser executado manualmente, ou a resolver algum problema que se poderia resolver com raciocínio lógico - mesmo que isso fosse levar muito tempo. Acreditamos que isso é verdadeiro em qualquer âmbito.
Entendemos por ‘processo’ ou ‘problema’ qualquer situação que se apresente para o programador ‘automatizar’. Programar é resolver o problema proposto etapa por etapa e codificar cada passo, até a solução. Ou seja, um programa é uma referência a um problema previamente resolvido. O que chamamos de algoritmo é simplesmente a sequência lógica de ações que levam ao resultado esperado (a solução do problema). Naturalmente, é necessária uma análise detalhada do problema, sem a qual não há a menor possibilidade de se desenvolver um algoritmo funcional.

Por exemplo, vamos supor que queremos que determinada página em nosso site seja acessada apenas por usuários com login e senha cadastrados no banco de dados. Para analisar este ‘problema’ vamos transportar a situação para o âmbito humano e pensar no site como uma casa, um local de diversão aberto ao público. Vamos imaginar que nessa casa há uma sala muito especial onde só entram certas pessoas selecionadas, cujos nomes estão em uma lista de convidados. Na lista, para cada convidado ainda há uma senha secreta que o mesmo tem que saber, senão não entra.
Ficou mais fácil, não? Se alguém pedisse que você ficasse na porta e controlasse a entrada dos convidados, aposto que não haveria problemas, você saberia o que fazer…
Veja este diálogo:

- Boa noite, sou convidado.
- Nome, por favor…
- Alberto.
- Deixe-me ver… ah sim! Alberto está na lista. Qual é a sua senha?
- Hum, ‘gato preto’.
- Senhor, infelizmente a senha cadastrada não é ‘gato preto’. Quer tentar novamente?
- Bem, foi minha mulher que fez esse cadastro… tente ‘bolinha’.
- Perfeitamente, senhor. Pode entrar, a senha está correta.
Então o porteiro abre a porta.

O diálogo acima contêm tudo que precisamos para implementar o programa solicitado. Precisamos apenas transportar de volta a nossa abstração para o universo real do problema.

Para organizar as etapas da solução em uma sequência lógica, vamos escrevê-la na forma de um pseudo-código.

Pseudo-código

Um pseudo-código é uma lista de ações, organizadas numa sequência lógica, para resolver determinado problema. É a formalização do algoritmo, o próprio programa escrito em linguagem humana. É extremamente útil, pois nos ajuda a identificar as possíveis falhas na lógica utilizada.
Existem algumas regras simples para tornar o seu pseudo-código mais inteligível:

• seja direto e objetivo
• use apenas um verbo por frase
• não use palavras de sentido ambíguo
• use frases curtas

O nosso algoritmo é simples e curto: começa quando o usuário clica no link que leva à nossa página protegida e termina quando o acesso é liberado ou negado. Existem algumas condições que ficaram implícitas no diálogo, mas temos que explicitá-las para o computador entender. São essas condições que determinarão se o acesso será permitido ou negado. Vamos ver o exemplo acima escrito dessa forma:

• Pedir login e senha
• Verificar se o par login/senha recebido corresponde a algum registro no banco
  • Caso negativo: voltar ao início (pedir login e senha)
  • Caso positivo: mostrar a página

O pseudo-código acima descreve um sistema que testa o par login-senha como uma coisa única. Funcionaria perfeitamente, mas em caso de erro, o script não saberia se o erro foi do login, da senha ou de ambos, o que não seria muito elegante - e não corresponde ao diálogo de nosso educado porteiro com o convidado. Podemos então fazer dois testes separados e enviar ao usuário uma mensagem de erro personalizada para cada caso:

• Pedir login e senha
• Verificar se o login recebido corresponde a algum registro no banco
  • Caso negativo: imprimir ‘login inexistente’ e voltar ao início
  • Caso positivo: comparar a senha digitada com a senha do banco
    • Caso negativo: imprimir ’senha incorreta’ e voltar ao início
    • Caso positivo: mostrar a página

É exatamente isso que queremos que o script faça: enquanto o usuário não acertar o login e a senha, o sistema continua solicitando esses dados. Qualquer pessoa ao ler esse pseudo-código é capaz de entender o que ele faz e de que forma, pois a linguagem adotada é humana. Existe uma outra forma de representar o algorítmo com uma linguagem gráfica, os diagramas de blocos.

Diagramas de blocos

Símbolo	Significado
	início ou fim do programa
	entrada de dados
	condição
	processamento
	saída de dados

Partindo da pressuposto de que um programa deve receber dados e processá-los de acordo com certas condições para então retornar o resultado, com os símbolos acima podemos representar qualquer algoritmo. Vamos então criar o diagrama para o exemplo acima (o primeiro):

Poderíamos também ter usado termos mais técnicos como os nomes das funções que pretendemos usar em cada etapa, mas essa não era a minha intenção, portanto ficaremos por aqui. O importante é perceber como funciona a lógica de construir uma funcionalidade em forma de algoritmo, pois mais adiante não precisaremos mais escrever o algoritmo antes de começar a programar, mas nunca deixaremos de fazê-lo em pensamento.

Esperamos ter ajudado…

Vou mostrar aqui um script em PHP que faz esse trabalho de catalogação e exibição automaticamente.

A idéia

Primeiro, o script tinha que ler um diretório (raiz do site) e guardar dados sobre todos os arquivos de tipos determinados, pela extensão - .HTM, .HTML, .PHP, etc. Legal, mas e quanto a arquivos PHP que não contém HTML, por exemplo? há muitos arquivos, inclusive .html que não deveriam ser listados… então precisamos também de algo que limite isso. Pensei em usar um array para isso, onde colocaria os nomes dos arquivos a serem excluídos. Ok, mas em grandes quantidades de arquivos isso ainda era insuficiente. Comecei então a ler os arquivos e pegar apenas os que tem alguma string entre as tags <title> e </title> e ler as META TAGs DESCRIPTION para descrever o arquivo na listagem. Os arquivos que não tem META DESCRIPTION podem também ser ignorados, bastando descomentar a linha a seguir na função printTree.

//if(empty($arr[’description’])) continue;

Bem, afinal, acho que ficou bem legal, mas é importante salientar que este script só vai ser realmente útil para sites que usam de forma eficiente as TAGs citadas, não repetindo um mesmo title para todas as páginas do site e com descrições específicas para cada página.

Para usar é preciso editar certas variáveis, como descrito no comentário dentro do script. Segue o script na íntegra:

<?php
/**
* Mapa do site
* ————
* @author Cau Guanabara
* @date 2006-10-01
*
* Este script cria um ‘mapa do site’ a partir dos arquivos dentro de determinado diretório.
* Os parâmetros buscados são os elementos HTML <TITLE> (para retirar o título) e
* <META NAME=description CONTENT=…> (para retirar a descrição). Se o documento não tiver o
* elemento TITLE, não será incluído na listagem. Se não tiver META Description, aparecerá
* na listagem, mas sem descrição.
* ———————————————————————–
* Para usar defina essas variáveis com os valores apropriados:
* $sitedir -> define o caminho para o diretório base da listagem (todos os sub-dir serão incluídos).
* $hostname -> define a URL para o diretório base da listagem, para compôr os links.
* $extensions -> define que tipos de arquivos serão incluídos na busca, pela extensão.
* $ignore -> define que arquivos e diretórios serão ignorados pelo sistema. Aqui deve-se usar
* apenas os nomes dos itens, não o caminho ou URL. Se houver vários itens com o mesmo
* nome em níveis diferentes, todos serão ignorados.
*
* Pode não ser conveniente usar este arquivo, se o conteúdo a ser listado é muito grande.
* Nesse caso, use este script para gerar o HTML e salve com extensão .html - será mais rápido.
*
* O HTML pode ser editado à vontade, bastando preservar as seções PHP. As tabelas estão vinculadas
* ao CSS e para modificar, edite as classes CSS abaixo.
*/
// ————-
// configurações
// ————-
// pasta raiz do site (path abs. ou rel. - não URL)
$sitedir = "./";
// URL do site para usar endereços absolutos (se ficar em branco, as URLs serão relativas)
$hostname = ‘http://localhost/’;
// extensões dos arquivos para listar
$extensions = array(’htm’,'html’,'php’,'asp’);
// nomes de pastas e arquivos que devem ser ignorados (em qualquer nível)
$ignore = array("sitemap.php");
// ————-
// isso foi necessário para pastas com conteúdo muito grande. O limite de 30 seg.
// não era suficiente, aumentei para 100 seg. (descomente se for necessário)
//set_time_limit(100);
$tree = dirItems($sitedir, $extensions, $ignore);
//print ‘<hr /><pre>’.print_r($tree,1)."</pre>\n";
printTree($tree, $hostname);
function dirItems($directory, $extensions, $ignore = array()) {
$items = array();
if($_dir = @opendir($directory)) {
while(($_file = readdir($_dir)) !== false) {
if(in_array($_file, $ignore)) continue;
if(is_file($directory.$_file) and preg_match("/\.(".join(’|',$extensions).")$/",$_file)) {
if($retit = readItem($directory.$_file)) $items[] = $retit;
}
if(is_dir($directory.$_file) and !preg_match("/^\./",$_file)) {
$items[$_file] = dirItems($directory.$_file.’/', $extensions, $ignore);
}
}
closedir($_dir);
}
return $items;
}
function readItem($item) { //print $item.’<br>’;
$ret = array(’name’ => preg_replace("/(^.+\/)([^\/]+)$/","$2",$item),
‘folder’ => preg_replace("/^.+\/([^\/]+)\/[^\/]+$/","$1",$item),
‘url’ => $item);
$conts = file_get_contents($item);
if(preg_match("/<title[^>]*>([^<]+)<\/title>/i", $conts, $matches)) $ret[’title’] = $matches[1];
else return false;
if(preg_match("/<meta[^>]*name=[\’\"]description[\’\"][^>]*content=[\’\"]([^\’\"]+)[\’\"]\s*\/?>/i", $conts, $matches))
$ret[’description’] = $matches[1];
return $ret;
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<meta name="description" content="Encontre facilmente as páginas que procura dentro deste site." />
<title>Mapa do site</title>
<style type="text/css">
<!–
body,td,th {
font-family: trebuchet MS, verdana, arial;
font-size: 14px;
}
body {
margin-left: 10px;
margin-top: 10px;
margin-right: 10px;
margin-bottom: 10px;
}
a.tit {
font-size: 16px;
font-weight:bold;
color:#000099;
}
a.tit:visited {
color:#005;
font-style:italic;
}
a.tit:hover {
color:#0000EE;
}
a.url {
color: #006633;
font-weight: bold;
}
a.url:visited { color:#666; font-style:italic; }
.tabela {
background-color:#FAFAFA;
margin-bottom:10px;
border:1px dotted #ccc;
width:500px;
}
.tabela td {
padding:5px;
}
fieldset.mapset {
padding:10px;
width:450px;
border:none;
margin-left:20px;
border-left:3px solid #E8E8E8;
}
fieldset.mapset legend {
font-size:120%;
color:#663333;
padding:3px;
}
–>
</style>
</head>
<body>
<?php
// criei essa função dentro do BODY para poder editar o html (…)
function printTree($tree, $host = ‘’, $retrue = false) {
$subs = array();
if($retrue) ob_start();
foreach($tree as $ind => $arr) {
if(is_string($ind) and count($arr) > 0) { // guarda as pastas para inserir no fim da lista
$sbs = printTree($arr, $host, true);
if(!empty($sbs))
$subs[] = "<fieldset class=\"mapset\"><legend>Diret&oacute;rio: ".
"<strong>$ind</strong></legend>".$sbs."</fieldset>";
continue;
}/**/
if(empty($arr[’url’]) or empty($arr[’title’])) continue;
// descomente para excluir da lista as páginas sem descrição
//if(empty($arr[’description’])) continue;
if($host) $arr[’url’] = preg_replace("/^\./", preg_replace("/\/?$/", "", $host), $arr[’url’]);
?>
<table class="tabela" border="0" cellpadding="0" cellspacing="0">
<tr>
<td><a class="tit" href="<?=$arr[’url’]?>"><?=$arr[’title’]?></a></td>
</tr>
<?php if(!empty($arr[’description’])) { ?>
<tr>
<td><?=$arr[’description’]?></td>
</tr>
<?php } ?>
<tr>
<td><a class="url" href="<?=$arr[’url’]?>"><?=$arr[’url’]?></a></td>
</tr>
</table>
<?php
}
if(count($subs) > 0) print join("\n",$subs);
if($retrue) return ob_get_clean();
}
?>
</body>
</html>

Como vimos, o arquivo é uma página - depois de configurado, basta exibir no navegador. Pode-se editar o HTML e o CSS na página, naturalmente. Espero que seja útil ao menos como base para algo mais detalhado.

Criei então alguns novos métodos adicionados ao objeto Date.prototype. O principal deles é o Date.toFormattedString(), que devolve a string enviada, com alguns caracteres especiais convertidos para valores de data e hora (veja a tabela de substituição), como na função date() do PHP.
O resultado pode ser em inglês ou português, mas pode-se também definir outros idiomas dinamicamente. Além do Date.toFormattedString(), há algumas outras funcionalidades. Segue o script e algumas explicações.

Há métodos para:

• Formatar data de acordo com uma string de formatação
• Trabalhar com nomes de dias e meses em qualquer idioma
• Converter datas para o formato aceito em arquivos RSS (RFC 2822)
• Converter datas para o formato aceito em arquivos ATOM (RFC 3339)
• Determinar o fuso horário em horas, minutos ou segundos
• Manter os valores do objeto sempre atualizados
• Acionar uma função de relógio a intervalos regulares
• Métodos extras
  • Array.walk -> aplica determinada função a todos os elementos do array
  • String.UCFirst -> transforma a primeira letra da string para caixa alta

Pegue o arquivo aqui date.prototype.js

Exemplo de uso:

Podemos definir o idioma de saída da função toFormattedString().
Para isso há os métodos addLang() e setLang(), que devem ser chamados antes de toFormattedString().
Apenas os idiomas inglês (’en’) e português (’pt-br’) estão disponíveis no sistema e o padrão é inglês.
Para usar português, basta chamar setLang(), passando o parâmetro ‘pt-br’.

Segue uma pequena referência das funções:

Adiciona nomes de dias e meses em um idioma ao sistema. Equivale a definir as propriedades Date.days[’id_do_idioma’] (array com os nomes dos dias) e Date.months[’id_do_idioma’] (array com os nomes dos meses) com os nomes enviados. Veja o exemplo 1.

Define o idioma de trabalho para id enviado. O id precisa fazer referência a um idioma existente (’en’ ou ‘pt-br’) ou que tenha sido adicionado previamente com Date.addLang(). Equivale a definir a propriedade Date.lang para o id enviado. Veja o exemplo 1.

Para adicionar e selecionar um idioma, use addLang() e depois setLang(), assim:

Para retornar valores formatados segundo especificações oficiais, há os métodos toRFC2822 e toRFC3339.

Essa função formata a data definida ao instanciar o objeto Date() de acordo com as especificações no RFC 2822.
>> Tipo de data suportado em formatos RSS.

Essa função formata a data definida ao instanciar o objeto Date() de acordo com as especificações no RFC 3339.
>> Tipo de data suportado em formatos ATOM.

Quando instanciamos um objeto Date, a hora de trabalho é relativa ao momento em que este foi instanciado.
Para construir um relógio, por exemplo, com precisão de segundos, normalmente se executa uma função que instancia o objeto novamente a cada segundo, para obter a hora atualizada. A função descrita a seguir executa esse processo, sem precisar instanciar o objeto novamente.

Mantém o momento para o qual o objeto Date aponta sempre atualizado, de acordo com o parâmetro interval ou a cada 1 segundo, se ele for omitido.. Se seu relógio não precisa de segundos (ou se não se trata de um relógio), seria aconselhável definir interval com um intervalo maior (1 minuto, por exemplo). Opcionalmente, executa a string de código code a cada atualização. Isso torna possível usar o método como uma espécie de setInterval, onde code é executado a cada interval milisegundos. Você pode querer apenas ter o objeto atualizado, para quando o usuário executar determinada ação, a hora estar certa. Para isso basta executar o método enviando o parâmetro interval ou nenhum.

Métodos extra

Tabela de substituição

A raiz desse problema é a mesma que impede o usuário de usar os botões do histórico em conteúdos carregados com ajax: a única página que existe para o navegador é a inicial, os conteúdos carregados com ajax não são vistos como novas páginas. Como resolver isso? Me ocorreu a idéia de enviar um comando em forma de string (como no script ajaxHistory) usando o hash. Na verdade, o hash foi usado (no lugar da query string) por que eu queria poder também usar o refresh… isso funcionou, mas só no IE. Quando a solução para o refresh for cross-browser (estamos trabalhando para isso…), vou divulgá-la aqui. Mas para usar os favoritos funcionou beleza.

A idéia é a seguinte: criei uma função que adiciona a página aos favoritos dinamicamente, acrescentando um comando javascript à URL, no hash (se o usuário for ao menu Favoritos e clicar em Adicionar a favoritos o sistema não vai funcionar). Ao carregar, uma outra função lê a URL e busca pelo comando, se ele existir, será executado no onload e o hash será esvaziado.

O princípio é bastante simples. Salvamos a página com um comando no hash que, se executado reproduz o estado da página no momento em que o usuário a salvou e executamos esse comando no onload da página. É preciso ser detalhista na hora de escrever essa string de comando, pois muitas vezes não basta executar a função que carrega os conteúdos, é preciso recriar todo um ambiente, setando variáveis e criando elementos.

Há uma variável-chave para o sistema funcionar, a jscommand. Ela deve ser atualizada a cada ação, com a string de comando. Se você resolveu usar o script ajaxHistory, fique atento por que nem sempre a string de comando será igual - quando executamos os comando do array de itens do histórico, trabalhamos num mesmo ambiente. Por outro lado, quando o sujeito voltar à nossa página a partir de um clique no seu menu Favoritos, esse ambiente deve ser inteiramente recriado, portanto, à vezes o comando para o ajaxBookmark, na variável jscommand precisa ser mais complexo.

Vamos ao código, pequeno e simples:

Um exemplo de uso (com ajaxHistory)

Bem, a princípio isso me pareceu uma boa solução, mas não funcionou satisfatoriamente em FF 1.5 e NS 7.2. Coisas estranhas acontecem, como a página ser carregada na barra lateral e o resultado da função não ser igual para NS e FF. A função addPanel na verdade não adiciona um item aos Favoritos, apenas cria um panel no Sidebar… Não sou usuário de Mozilla, uso apenas para testar (digo isso sabendo que vai parecer um sacrilégio para alguns, mas tenho que confessar: eu uso o IE!).

Espero que aproveitem a idéia mas, principalmente, espero que alguém que conheça os meandros do Netscape e do Firefox tenha uma boa idéia e possa fazer um ajuste.

Sugestões e comentários são muito bemvindos.

O assunto é delicado, pois uma parcela considerável dos profissionais da área considera que o termo não passa de uma ‘buzzword’ (um termo belo, mas vazio de significado real), que é apenas uma onda criada para explorar a necessidade de constante atualização exigida aos profissionais da área, etc., e que os criadores dessa ‘palavra mágica’ (que sacudiu toda a área de TI) ganham muito dinheiro divulgando e ensinando algo que eles próprios inventaram - uma espécie de golpe de marketing. Bem, este é um ponto de vista embasado e tem suas razões de ser, mas somente após conhecer as tecnologias, idéias e conceitos por trás da legenda ‘Web 2.0’ é que poderemos julgar. Portanto, mãos à obra.

Começaremos dizendo que ‘Web 2.0’ não é uma linguagem, nem um programa, nem um protocolo nem nada do gênero. É apenas uma idéia, um conjunto de ‘regras’ que sugerem uma nova maneira de fazer e usar a internet. Algumas tecnologias novas (e outras nem tanto) associadas a conceitos como padronização, usabilidade e interatividade e ao ‘novo nível’ de capacitação da média dos internautas mudou o panorama da web e um ‘novo paradigma’ precisou ser formulado – e esse novo paradigma foi chamado ‘Web 2.0’.

• Conteúdo participativo A possibilidade de interatividade e participação do usuário na criação e classificação dos conteúdos passou a ser uma característica comum a grande parte dos sites de sucesso atualmente e estudos comprovam que cada vez mais o internauta valoriza sites que permitem sua participação. Tanto que empresas como Yahoo! e Google estão envolvidos de corpo e alma na afirmação desses novos conceitos.
• Classificação pessoal dos conteúdos Foram criados alguns sites que viraram sucesso imediato, como o del.icio.us, que permitem ao usuário classificar endereços da web com TAGs (rótulos) personalizados, organizando a ‘sua internet’ a sua própria maneira, além de poder compartilhar sua relação de ‘favoritos online’ com outros internautas. É o que se chama hoje ‘social-bookmarking’ ou ‘tagsonomia’.
• Design e usabilidade O design também sofre modificações com a Web 2.0, tendendo a um estilo mais clean, que valoriza também os espaços em branco. Primeiro que a preocupação com o grau de usabilidade do site passa a ser primordial, depois, a variedade de tipos de mídia e tamanhos de monitor torna a apresentação do site uma questão bem mais complexa, exigindo o uso de CSS. A informação deve estar à mão, a poucos cliques de distância e dentro de uma hierarquia de organização que seja de fácil entendimento ao usuário.
• Novas tecnologias e novas abordagens para velhos temas O Javascript, linguagem de script natural do HTML, surgiu para dar um mínimo de autonomia às páginas HTML. Mas hoje, na versão 1.5, o Javascript é uma linguagem de programação poderosa, capaz de interagir com outras linguagens e possibilitando ao desenvolvedor criar sistemas mais rápidos e confortáveis, efetivamente mais interativos. Enfim, mais próximos das aplicações de desktop.
• A web como plataforma de desenvolvimento Acabou a era do conteúdo estático. Ao invés de ‘páginas’, agora teremos cada vez mais ‘programas’ online. A rede passou a oferecer tudo: linguagens de servidor / cliente mais poderosas, com alta portabilidade, além de conteúdo farto - muitos sites passaram a oferecer seus conteúdos na forma de serviços ou ‘web-services’, que podem ser acessados e utilizados por outros sites ou aplicativos.
• Sintetizando conteúdos Com o advento dos ‘web-services’, tornou-se possível organizar conteúdos de várias fontes numa única página e vários sites começaram a oferecer esse tipo de serviço, denominado ‘mash-up’. Esses sites tem uma relação de conteúdos disponíveis e o usuário ‘monta’ sua própria página.
• Padronização Com a diversidade de recursos e tipos de dispositivos de mídia capazes de exibir um site da internet, a necessidade de seguir certos padrões de desenvolvimento se tornou maior que nunca. A internet, essa verdadeira ‘Torre de Babel’, precisava mesmo de um pouco de ordem… Surgiu então a W3C e outras organizações com a finalidade de promover essa ‘linearização’, para que em breve tempo não precisemos nos preocupar com as diferenças entre os navegadores. O que chamamos de ‘programação crossbrowser’ é na verdade um conjunto de ‘gatilhos’ para evitar um problema que é, em essência, desnecessário.

A justificativa da negação

A verdade é que as tecnologias que servem à internet vêm se aprimorando (e se modificando) desde que tudo começou. O ambiente da internet foi concebido originalmente para suportar a linguagem HTML, com textos, imagens, links, sons, enfim, poucas opções de componentes para exibir um conteúdo estático e não-interativo, mas isso começou a se modificar imediatamente e num processo gradual e constante, até chegar ao que é a internet hoje. Isso significa que o que alardeiam como ‘Web 2.0’ não passa da evolução natural da coisa e que se ninguém falasse nada a respeito, não faria a menor diferença. Todos os tópicos citados acima como diretrizes de um novo movimento, já existem há tempos, excetuando-se as funcionalidades adicionadas pelas novas versões de programas e linguagens envolvidos no processo. Então qual a vantagem de vender esse peixe agora, como se fosse um ‘novo produto’, quando tudo não passa da mesma coisa de sempre?

Qual a vantagem?

A vantagem está justamente em alardear a Web 2.0 como ‘a nova realidade da internet’, como um ‘novo padrão a seguir’, criando com isso a possibilidade de ‘moldar o futuro’ e criar padrões para orientar os desenvolvedores e evitar que a confusão que reina há tanto tempo permaneça. ‘Web 2.0’ é um marco, um divisor de águas, uma mudança de paradigma muito bem vinda, mas não é algo fácil de apreender nem nada palpável… é apenas uma idéia. E só quem navega com alguma facilidade pelo oceano das idéias percebe que o mundo das coisas palpáveis é o apenas o reflexo delas. São as idéias que dão origem às coisas e qualquer movimento sem a sustentação de uma idéia é vazio de significado. Um pouco de filosofia talvez ajude a explicar o que quero dizer: web 2.0 não passa de uma idéia, mas a partir dessa idéia vamos conseguir, no futuro, uma atitude mais coerente e embasada por parte dos zilhões de webdesigners e webdevelopers pelo mundo afora. Se todos que tem uma tesoura se dissessem barbeiros e cabeleireiros, já imaginou como seriam os cabelos por aí? … certamente iguais a certos sites que ainda vemos em grande número na internet…

Web 2.0, ok. Mas quando isso acontecerá?

Surpresa: já acontece há algum tempo. É isso mesmo, a Web 2.0 já é uma realidade, nós é que não tínhamos percebido. O termo foi usado pela primeira vez simplesmente para definir o abismo que há entre os sites da década de 90 e os atuais, e entre a atitude dos internautas daquela época e a dos de hoje – melhor informados, mais familiarizados com os processos e interfaces da internet e principalmente mais exigentes e participativos. Como foi dito no tópico acima, o termo ‘Web 2.0’ veio apenas ‘batizar’ a nova maneira de fazer, separando o joio do trigo e determinando certas diretrizes de procedimento para o futuro.

Um movimento maior e anterior…

Antes de se inventar o termo web 2.0, já havia um movimento no sentido de padronizar a internet, com a criação de organizações como a w3c e outras, que tem por finalidade desenvolver padrões (comumente chamados ‘web-standarts’) para imprimir um certa ordem à bagunça que é a internet. Para os desenvolvedores, principalmente no tocante às tecnologias ‘client-side’, que dependem do navegador, a padronização é um sonho, significando uma redução substancial do código. E o termo ‘web 2.0’ define sites que, além de levar em conta a participação do usuário, abraçaram o movimento ‘web-standarts’ – que, poderíamos dizer, é a especificação da parte tecnológica do padrão definido pelo termo ‘web 2.0’. Por este aspecto, o que se chama hoje de ‘web 2.0’ pode ser visto como uma nova abordagem, mais completa, daquele mesmo movimento que começou com os web-standarts.

Conclusão

Bem, visto tudo isso, acho que fica claro que sou um entusiasta da web 2.0. Considero que esse papo de que isso nunca existiu, não significa nada, etc., é coisa de quem não conseguiu perceber as implicações implícitas no movimento. A febre ‘web 2.0’ é apenas um ‘ritual de passagem’, algo que veio para lembrar a todos os envolvidos que a web agora mudou. É a evolução natural sim, mas era preciso falar disso, acordar todos e fazê-los ouvir. Não que os sites padrão ‘web 2.0’ sejam melhores que os mais antigos, mas é que ao seguir as tendências globais, você se torna mais compatível com o futuro, além de dar uma perspectiva de sobrevivência maior aos seus sites e poder contar com mais recursos na hora de desenvolvê-los.

O momento é de inversão: os usuários, que sempre tiveram que suar a camisa para compreender e usar as interfaces que lhes eram oferecidas, agora têm o comando e estão forçando os desenvolvedores a seguir as suas decisões. O público agora é rei - é a tão falada ‘democracia na rede’ se tornando realidade.

Por fim vou afirmar que, mesmo não sendo um conceito tão objetivo quanto muitos gostariam, a tal da ‘Web 2.0’ existe sim - e será um marco na história do desenvolvimento web.

Bem, todos já sabemos que comandos em javascript não ativam os botões de histórico do navegador, mesmo que mudem 100% do conteúdo exibido. Isso não é legal, pois sabemos que o usuário busca usar os recursos que conhece e o botão ‘Voltar’ é uma instituição, existe desde que o mundo é mundo. Eu me sentia meio que ‘na obrigação’ de possibilitar isso ao usuário.

Pensei então, há alguns meses em uma solução - que me serviu no momento, mas que não ativava os botões, apenas criava um ‘histórico de comandos’ num array, com funções para adicionar, exibir e testar itens do histórico. Com isso eu fazia os meus próprios botões de histórico. Achei que fosse suficiente, mas hoje vejo que não, pois na maior parte dos casos o usuário nem entende que há um histórico ‘paralelo’ e que ele precisa clicar em outros botões para navegar…
Veja o script original:

Caí de cabeça atrás da solução, que eu já sabia, tinha algo a ver com a propriedade hash do objeto location. Descobri algumas possibilidades, a começar pelos famosos frameworks (que eu abomino…), algumas funções interessantes que só funcionavam em Mozilla, outras gigantescas demais para o meu gosto. Tentei então entender como as coisas eram feitas e fazer eu mesmo. Este é sempre o método mais enriquecedor (mas nem sempre é o mais eficiente… é bom lembrar -rsrsrs).

Entendendo

O objeto window.location tem uma propriedade chamada ‘hash’, que mostra ou define aquela parte da URL que vem no final, depois do caracter ‘#’ - que usamos para navegar para diferentes pontos na mesma página, com, por ex.:

Pois é, ele é a chave para o histórico do navegador, pois ao mudar o hash, mudamos a URL. Então se ao executar um comando, eu mudar o hash o navegador armazena como uma nova página? A resposta é não. Se não há um clique explícito do usuário em um link como o descrito acima (com um A NAME="…"), ao clicar no botão Voltar, nada acontece! O IE nem habilita o botão!!! Bem, mas a URL está diferente e é isso que vamos usar. Usaremos uma variável para armazenar o hash e um setInterval para testá-lo a intervalos regulares. Dê uma olhada nesse link: http://juliogreff.wordpress.com/2006/10/20/ativando-o-botao-voltar/.

Com o script que o Júlio mostra, resolve-se a questão. Mas resta um problema: o IE não habilitou o botão voltar apenas com a mudança do hash… Mais pesquisas e mais pesquisas para achar a solução, que quando foi encontrada me pareceu tão óbvia que não sei por que não pensei nisso antes (sempre pensamos isso, né?). Quando carregamos um frame ou iframe o IE cria um novo item no histórico! Veja a página de onde tirei a idéia: http://www.contentwithstyle.co.uk/Articles/38/fixing-the-back-button-and-enabling-bookmarking-for-ajax-apps.
Esse exemplo é crossbrowser, mas muito complicado. Serviu para esclarecer, mas não tive vontade de usá-lo.

Bem, baseado nesses scripts resolvi criar um terceiro, fundindo com o que já tinha pronto (mostrado acima) criei o objeto ajaxHistory. Vou falar sobre a lógica que usei antes de mostrar o script. Basicamente preservei os métodos e propiedades do antigo objeto e acrescentei novos métodos para permitir o uso do objeto history do navegador.

Em nosso objeto haverá um array para armazenar os comandos (como strings) chamado ajaxHistory.items e um inteiro que indica o índice do item exibido no momento, ajaxHistory.currentIndex. O sistema original funciona da forma mais simples possível. A cada comando que modifique o conteúdo da página, executamos ajaxHistory.add enviando uma string que se executada como comando reproduz a operação que modificou a página. Depois podemos usar os métodos ajaxHistory.go ou ajaxHistory.goTo para navegar pelos itens do nosso ‘histórico de comandos’. Além do método goTo, o array ajaxHistory.captions foi adicionado, possibilitando ajustar o título da página de acordo com o item exibido. Aí podemos usar ajaxHistory.hasBack e ajaxHistory.hasForward para testar se há itens atrás ou adiante do atual e assim habilitar ou desabilitar nossos botões personalizados de histórico.

Ok, mas e para usar os benditos botões de histórico do browser? Para isso vários métodos foram criados, mas para executar, basta chamar o método ajaxHistory.activateBrowserHistory no onload da página, uma única vez. Isso dispara uma série de eventos que em conjunto habilitam o histórico do navegador. Vamos a eles.

A lógica e a execução da coisa são diferentes para Mozilla e IE (novidade…).

Em ambos os casos o hash é modificado ao criar um novo item ou ao carregar um item do histórico (ajaxHistory.setHash).

No Mozilla criamos um setInterval chamando o método ajaxHistory.checkHash a cada 1/10 de seg. testando se o hash é igual a ajaxHistory.currentIndex, se for diferente, o usuário clicou no botão voltar (ou avançar). O hash é setado com o valor do índice do item no array ajaxHistory.items, então ajaxHistory.goTo é chamado com o hash como parâmetro.

No IE um iframe é inserido na página, com display:none. Este iframe carrega o arquivo ‘historyframe.html’ que deve ser criado como descrito abaixo:

No caso do IE, ajaxHistory.setHash recarrega o iframe enviando na query string o valor do índice, assim: ‘historyframe.html?2′, por exemplo. O arquivo ‘historyframe.html’ ao ser carregado testa o índice enviado na URL com o hash na URL da janela principal, se forem diferentes, ajaxHistory.goTo é chamado com o índice enviado na URL como parâmetro.

O Mozilla, ao contrário do IE, habilita os botões mas não há ação mesmo quando o iframe é recarregado, portando os dois métodos foram necessários. Bem, lá vai o script:

As comunidades da rede são uma febre, juntamente com os blogs. Pode-se encontrar todo tipo de informação, de qualquer assunto, inclusive dados pessoais dos internautas.
O Orkut, que tem tido tantos problemas com a justiça por conta dos conteúdos dos usuários, é um exemplo excelente. Entre na página de um usuário que não tem vocação para hacker (falo da média dos usuários) e perceba a inocência com ele se expõe, informando onde mora, nomes de parentes, fotos, etc. Até telefone já vi divulgado.

Em qualquer comunidade que ingressamos, a primeira coisa que você tem que fazer é informar seu e-mail. Aliás, não se pede mais para o usuário criar um login, esse conceito está ficando ultrapassado. Agora o login é o seu e-mail na maior parte dos sites, você só escolhe a sua senha. Bem, ao entrar a primeira sugestão é (e isso é quase invariável): fale um pouco de você, preencha o seu ‘profile’, ou seja, informe para nós os seus dados pessoais. Essas informações são usadas, como vemos nos jornais todos os dias, por bandidos, hackers e outros, talvez piores…

Isso tudo me faz lembrar a já quase esquecida (e mais possível que nunca) ‘teoria da conspiração’. É verdade, os dados estão totalmente descentralizados em milhões de servidores pelo mundo afora, como achá-los e usá-los? Respondo que tudo é uma questão de proporcionalidade. Se estivéssemos falando de uma rede local, com 10 máquinas, com um computador de última geração seria possível, não? Nem seria caro montar uma máquina capaz de fazer o trabalho bem rapidamente, talvez uns 2 mil dólares?. Agora imagine que você tem uma verba de 2 bilhões de dólares para varrer a internet… começa a parecer menos impossível, não?

Aí surge o Google, tomando conta de todos os setores mais visitados da internet em pouquíssimo tempo e oferecendo um e-mail com 2 giga de espaço em disco (que disco? Onde está esse disco? Quem é o dono desse disco?) e com o conselho explícito: ‘não jogue mais nada fora!’ (deixe que nós tomamos conta dessas informações para você).

Ora, informação sempre foi sinônimo de poder, quanto mais no mundo de hoje. Agora eu pergunto: será que sou neurótico ou empresas como o Google podem tirar proveito dos dados que guardam? Ou até terem ligações com agências internacionais de inteligência? Sabemos que o tio Sam anda em crises de neurose com os terroristas e acabou de desembolsar alguns trilhões de dólares numa guerra estúpida… que tal então aumentar nosso orçamento de 2 mi para 1 tri? Mais viável?

Não, não fique assustado, pois realmente sou um pouco neurótico.
Claro que tudo que estou falando são absurdos jurídicos – toda empresa tem deveres legais e não pode (legalmente) se prestar a esse tipo de papel, como negociar os dados sob sua guarda. Se você acredita numa atuação legal e ética por parte daqueles a quem interessa controlar esses dados, fique tranqüilo.

Sou programador e acredito no ‘open-source’, acho que o compartilhar é o grande lance da rede. O que questiono é até onde devemos nos expor pessoalmente ao invés de apenas divulgar nossas idéias. Alguém mais inteligente que eu já disse que as pessoas interessantes falam sobre idéias enquanto as medíocres falam sobre pessoas – incluindo, naturalmente, ter a si mesmo como tema principal. Não que seja apenas o egocentrismo que leve as pessoas a divulgar seus dados pessoais na rede, a inocência é enorme também.

Compartilhe seus arquivos e idéias, mas não se exponha demais… a privacidade está se tornando um bem quase impossível de se conseguir e eu o desejo. Por isso tento dificultar em lugar de facilitar as coisas… falo isso rindo às gargalhadas! Devo ser mesmo um maluco neurótico.