HTML5 – Tag aside

Dando continuidade as explicações sobre as novas tags do HTML5, você já sabe especificar o doctype, já fez o seu menu utilizando a tag nav, como você deve classificar o conteúdo relacionado ao seu conteúdo principal?

aside – conteúdo relacionado

A tag <aside> não é para fazer colunas como eu já li por aí, nas dicas para escrever um bom HTML eu falei: semântica na escrita, ignore o layout.

A tag aside define uma área de conteúdo relacionado ao seu conteúdo principal (que provavelmente será um article, o "filé do conteúdo" – vou tratar em outro post já começado), então pode fazer sentido você utilizar isso para uma barra lateral – desde que o conteúdo esteja relacionado ao seu conteúdo principal.

Um exemplo do @elcio no curso da W3C é o uso do aside para as listas de comentário. Isto resolve a dúvida do uso de sectionou article para comentários. Desde que li as definições eu tenho em mente usar apenas um article por página – pensando em SEO, este article está reservado para o conteúdo principal, que eu quero que seja indexado e considerado importante pelos buscadores, pois ele é o conteúdo mais importante para o meu usuário.

Vou continuar escrevendo diversos posts sobre HTML5 durante o curso, para quem quiser acompanhar mais de perto sigam @odesenvolvedor que estou pulicando as dicas rápidas por lá!

(Os posts feitos durante o curso serão atualizados com as correções, estou "correndo" para não perder nada de conteúdo do curso).

Html5 – tag NAV

Se tudo der certo esta semana eu vou participar do curso de HTML5 da W3C e para me preparar para o curso eu dei continuidade aos meus estudos e testes com HTML5.

Prometi que vou abordar em posts por aqui algumas tags específicas do HTML5, já expliquei a importância do uso do html5 doctype, hoje vou falar da tag NAV, que traz melhorias na semântica e consequentemente na indexação das páginas.

<nav>

A tag <nav>, como o nome indica, defina uma seção de navegação no documento – uma lista de links. No HTML4 ainda é comum ver menus de navegação com o seguinte código:

<ul class="nav">
    <li><a href="#" title="Home">Home</a></li>
    <li>
<a href="#" title="Sobre">Sobre</a></li>
    <li>
<a href="#" title="Contato">Contato</a></li>
</ul>

Com as mudanças do HTML5 alguns microformats foram transformados em tags, o <nav> é uma delas. Um menu agora poderá ser escrito da seguinte forma:

<nav>
    <a href="#">Home</a>
    <a href="#">
Sobre</a>
    <a href="#">
Contato</a>
</nav>

Uma seção focada na navegação melhora a semântica do documento e pode facilitar muito a navegação através de leitores de tela, melhorando a acessibilidade do site.

Segundo a W3C elementos como "próximo" e "anterior" devem estar dentro de uma <nav>, portanto acredito que a tag também pode ser usada para paginação, por exemplo.

SEO e a tag <nav>

Além da questão da acessibiliade e semântica sem dúvida a <nav> vai influenciar na indexação dos buscadores, visto que os links são os canais do "juice" das páginas. Acredito que o uso não deve ficar preso apenas a menu e a o <nav> deve ser aplicado a qualquer  "seção de navegação" da sua página, por exemplo:

  • Menu principal
    Exemplo acima, menu no header ou barra lateral para as páginas principais do site
  • Histórico
    No caso de blogs é comum ter um "histórico" – é uma seção de navegação, faz sentido o uso da classe
  • Próximo / Anterior e paginação
    Também são elementos de navegação e bastante usados em muitos blogs.
  • Breadcrumb
    Importante para a navegação do site, semanticamente faz muito sentido estar classificado como navegação.
  • Lista de links dentro do conteúdo
    Bacana para a navegação e importante para SEO, é como o uso de ferramenta de links recomendados, que adivinha só? É um conjunto para navegação… 😉

 

Dicas

Algumas coisas que acho que vale a pena ressaltar…

<nav> não é <menu>

No html5 existe a tag menu e isso pode causar confusão em alguns desenvolvedores, porém para o menu de navegação de um site o correto é o uso do <nav>. A descrição da tag menu é que ela é uma lista de comandos, então faz mais sentido o uso dela em aplicações web onde o menu é utilizado para listar comandos, e não links de navegação.

Utilize o doctype correto

Você precisa dizer para o seu navegador como ele deve interpretar o seu documento, para isso utilize o doctype do HTML5 sempre que ele for utilizado.

<nav> aceita listas

Acabei de questionar no curso de HTML5 sobre o uso de <nav> e lsitas, não é necessário utilizar uma lista dentro do elemento <nav>, portanto você pode ter o seguinte:

<nav>
  <li><a href="#" title="Title">Item</a></li>
  <li><a href="#" title="Title">Item</a></li>
  <li><a href="#" title="Title">Item</a></li>
  <li><a href="#" title="Title">Item</a>
     <nav>
        <li><a href="#" title="Title">Item</a></li>
        <li><a href="#" title="Title">Item</a></li>
      </nav>
  </li>
  <li><a href="#" title="Title">Item</a></li>
</nav>

 

O <nav> não é um UL, ele aceita parágrafos, listas, links, etc. 🙂

Salvando objetos com ID definido no Data Mapper (CI)

Desde que comecei a estudar e utilizar o Code Igniter eu recomendo o uso do ORM Data Mapper, que facilita a vida nas consultas ao banco de dados (leia: tutorial do Data Mapper no Code Igniter), esta semana ele mais uma vez se mostrou muito útil enquanto eu fazia a migração do banco antigo do And After para o novo.

Depois de dominar (yeaaaah) relacionamento de tabelas com o Code Igniter (usando o Data Mapper) e finalizar o sistema do And After neste framework estou fazendo a migração de todo o conteúdo para a nova plataforma: textos, comentários, cadastro de usuários, logs, tags, blogs…

Achei que seria extremamente trabalhoso, pois toda a estrutura de banco foi alterada – recomecei o sistema do zero sem pensar na migração, fiz isso para evitar "puxadinhos" e gambiarras (que com o crescimento de sistema, estava cheio) e desenvolver tudo direito, do zero, um sistema novo.

No ônibus voltando para São Paulo fiz em alguns minutos a migração dos usuários e iniciei a dos textos (que será um pouco mais complicada devido aos relacionamentos), mas tive um problema com o Data Mapper: não perder os ID"s dos objetos que estão sendo migrados.

Como salvar um objeto com um ID existente?

O Data Mapper usa o atributo ID do objeto para verificar se ele deve fazer um insert ou um update, se o objeto ID existe ele fará um UPDATE, portanto você não consegue setar o ID de um objeto e usar o $object->save();, pois ele fará um update mesmo que o objeto não exista (e não vai acontecer nada no seu banco).

Para isso o Data Mapper tem a função save_as_new, segue um exemplo abaixo:

$user = new User();
$user->id = 1;
$user->login = "Admin";
$user->password = "password";
$success = $user->save_as_new();

Se não deu nenhum problema no seu banco (neste caso ele deveria estar limpo) você acabou de criar um usuário "Admin" com o id 1na sua tabela.

Problemas comuns

Após fazer a migração pode acontecer problemas ao tentar salvar novos objetos na tabela, isso pode acontecer porque o auto_increment (do ID) não foi atualizado – e está tentando inserir um novo objeto na tabela com um ID que já foi registrado "na mão".

Para facilitar o entendimento vamos a ao exemplo do caso da migração do And After. Existem aproximadamente 1.500 usuários cadastrados no site, após a migração o último ID utilizado na tabela de usuários foi o 1600 (devido a usuários excluídos, testes no banco, etc).

Preciso avisar a minha tabela que o próximo auto_increment (ID) é 1601, e não 1 (que seria o primeiro inserido de forma "natural", sem ID setado). O código abaixo executa esta atualização no banco:

// Update MySQL AUTO_INCREMENT:
$user->db->query("ALTER TABLE `users` AUTO_INCREMENT = 1601;");

Agora a migração da tabela users está completa e é possível utilizar ela normalmente.

Para mais dúvidas sobre o save leia a documentação do data mapper (EN).

HTML5 Doctype

Depois de compartilhar algumas dicas para fazer um HTML, tive um feedback muito positico e alguns galeritos pediram para eu abordar mais as mudanças e novidades do HTML5 por aqui – agora que estou acompanhando mais de perto a evolução do HTML5 resolvi começar a compartilhas coisas simples e exemplos com vocês. 🙂

Recomento que você veja o infográfico sobre HTML5

HTML5 Doctype

No HTML 4 existiam três tipos diferentes de doctype, no HTML5 ficou mais simples, existe apenas um tipo, e deve ser inserido no início do documento:

<!DOCTYPE HTML>

Para que serve o Doctype no HTML5?

Segundo o W3C o Doctype nao chega a ser uma tag HTML, é uma especificação para o browser saber qual é a marcação e o tipo de documento que ele está interpretando.

No HTML 4 era necessário associar o doctype a um DTD (definição de tipo de documento), agora não é necessário associar o doctype a um DTD pois o HTML5 não é baseada na SGML (Standard Generalized Markup Language).

É necessário o uso do doctype para que os navegadores se comportem como devem e interpretem corretamente as tags do HTML5.

 

Espero em breve mostrar para vocês O Desenvolvedor já em HTML5, ou pelo menos alguns exemplos que estou fazendo para testes. ;D

Entendendo o relacionamento de tabelas no banco de dados

Dando continuidade ao tutorial do Data Mapper para Code Igniter hoje vou escrever sobre um assunto que sempre complicou minha vida quando o assunto é MySQL: relacionamento de tabelas.

Este post explicará apenas o básico sobre relacionamento, quando finalizei ele tratando de relacionamento e do uso de relacionamentos no Data Mapper ele acabou bastante extenso, optei por quebrar o post em dois para facilitar a leitura.

Se você já entende de relacionamentos não perca tempo com este post, aguarde o tutorial específico de como usar relacionamentos no Data Mapper para Code Igniter (será linkado neste post assim que for publicado!).

 

O que é relacionamento de tabelas?

Primeiro vamos entender um pouco sobre o funcionamento e tipos de relacionamento, deixando de lado o Data Mapper e falando apenas da questão lógica do negócio.

O relacionamento existe quando um ou mais dados de uma tabela estão relacionados de alguma forma com um ou mais dados de outra tabela.

Por exemplo, temos uma tabela d usuários (users) e uma tabela de posts (posts), cada usuário pode publicar infinitos posts porém cada post poderá ter apenas um usuário. Estas tabelas estão relacionadas.

Existe também relacionamento de dados de uma tabela com outros dados desta mesma tabela. Um usuário (user) pode ter vários amigos da mesma tabela (user), então os dados estão relacionados com dados da mesma tabela.

Agora vamos aos tipos de relacionamento:

 

Relacionamento um para um (one to one)

Neste tipo de relacionamento um dado de uma tabela equivale a um dado em outra tabela exatamente.

Por exemplo um usuário (table users) está relacionado a um endereço na tabela adress, e cada endereço só está relacionado a um usuário.

 

Relacionamento um para muitos – One to Many

No relacionamento um para muitos um dado da tabela um pode estar relacionado a diversos dados da tabela dois, porém cada dado da tabela dois estão relacionados a apenas um dado da tabela um.

Por exemplo um user (table users) pode estar relacionado a diversas casas (table houses), porém cada casa só está relacionada a um user.

 

Relacionamento muitos para muitos – Many to many

No "many to many" os dados da primeira tabela podem estar relacionados a diversos dados da segunda tabela e os dados da segunda tabela também podem estar relacionados a diversos dados da primeira tabela.

Exemplo: um usuário pode ter diversas habilidades (user com diversos relacionamentos para a tabela skills) e cada habilidade também pode estar relacionada a diversos usuários (dado da tabela skill relacionado a diversos dados da tabela users).

 

 

Estrutura das tabelas para relacionamento

Agora que já conhecemos os tipos de relacionamento, vamos entender como estruturar nosso banco de dados para permitir o acesso fácil aos dados relacionados.

Quando o relacionamento é um para um ou um para muitos podemos estruturar as colunas diretamente na tabelas relacionadas, continuando com o exemplo da tabela users e posts, na nossa tabela posts  podemos ter uma coluna chamada user_id  que identifica a qual user está relacionado aquele post.

Table users

id | name | email

 

Table posts

id | title | content | user_id

 

No exemplo acima temos automaticamente um relacionamento um para muitos de users->posts e um para um de posts->users.

Quando o relacionamento é muitos para muitos a estrutura do exemplo acima não é viável (a não ser com uma boa gambiarra, com split de valores e performance porca como eu já fiz). A solução é "quebrar" o relacionamento e inserí-lo em uma nova tabela destinada somente a isso.

Vamos supor que temos uma tabela images onde ficam armazenadas as imagens relacionadas aos posts. Um post poderá ter diversas images e uma image poderá ser utilizada em múltiplos posts. Para fazer este relacionamento criamos uma tabela de relacionamento, que para ilustrar este exemplo chamaremos de images_posts e terá a estrutura abaixo:

TABLE IMAGES_POSTS

id | image_id | post_id

 

Com este tipo de estruturação podemos relacionar infinitos posts com infinitas images. Por exemplo, o post com id = 4 poderá ter as imagens com id = 8, id = 9 e id = 10.

Teremos:

TABLE IMAGES_POSTS

id | image_id | post_id

1  | 8                | 4

2  | 9                | 4

3  | 10              | 4

 

Pronto, estrutura feira e as images 8, 9 e 10 também poderão estar relacionadas a outros posts também, apenas inserindo mais dados nesta tabela de relacionamento.

 

O próximo post explicará como inserir, acessar e manipulas dados de tabelas com relacionamento utilizando a ferramenta ORM Data Mapper para Code Igniter!

Espero que este post seja uma boa referência para estudos, para dar continuidade ao aprendizado veja alguns livros sobre MySQL que podem te ajudar.