eçar, é muito comum usar o mesmo arquivo para exibir o formulário e processar os dados. Primeiro, a página aparece com o formulário em branco. Depois que o usuário envia, o PHP detecta que há dados no $_GET e passa a exibir a resposta. Isso cria um fluxo natural e fácil de entender. O aluno começa a enxergar que o PHP reage ao estado da página, e não apenas executa comandos soltos.

Os exemplos dessa aula costumam girar em torno de algo bem cotidiano, como uma saudação personalizada ou um campo de busca. Você digita um nome, envia, e o site responde: “Olá, Maria!”. Pode parecer simples, mas isso já envolve vários conceitos importantes ao mesmo tempo: HTML para o formulário, método GET para envio, PHP para receber os dados e lógica para decidir o que mostrar. É um pequeno sistema completo, mesmo sendo básico. E isso ajuda muito a ganhar confiança.

Um ponto que merece atenção especial é o tratamento do texto recebido. Quando o usuário digita algo, ele pode colocar espaços a mais, caracteres estranhos ou até deixar o campo vazio. Por isso, a Aula 7 costuma introduzir pequenas funções de cuidado, como remover espaços extras ou exibir o texto de forma segura. Não é ainda uma aula de segurança profunda, mas é o primeiro passo para entender que dados vindos do usuário precisam ser tratados com carinho. Esse cuidado evita resultados feios na tela e prepara o terreno para boas práticas mais adiante.

Também é importante reforçar que GET não é indicado para tudo. Justamente por aparecer na URL, ele não deve ser usado para dados sensíveis, como senhas ou informações pessoais. Mas isso não significa que GET seja “ruim”. Pelo contrário: ele é perfeito para situações em que o resultado pode ser compartilhado, salvo nos favoritos ou revisitado depois. Ensinar isso cedo ajuda o aluno a escolher conscientemente a ferramenta certa para cada situação, em vez de usar tudo no automático.

No final da Aula 7, o aluno percebe uma mudança clara: o site deixa de ser um conjunto de páginas “que mostram coisas” e passa a ser um espaço de interação. O usuário escreve algo, o PHP responde. Esse diálogo é a base de qualquer aplicação web, do formulário mais simples ao sistema mais complexo. Dominar o GET é como aprender a ouvir antes de falar: você entende como os dados chegam, como interpretá-los e como devolver uma resposta coerente.

Em resumo, a Aula 7 ensina mais do que um método de envio de dados. Ela ensina o começo da relação entre usuário e sistema. Ao aprender a trabalhar

começo da relação entre usuário e sistema. Ao aprender a trabalhar com formulários GET, verificar se os dados existem e responder de forma clara, o aluno dá um passo fundamental rumo a aplicações reais. E, principalmente, começa a entender que programar para a web é, acima de tudo, criar experiências que reagem às ações das pessoas.

Referências bibliográficas

ALMEIDA, Marco Antonio. PHP: Programando com Orientação a Objetos. São Paulo: Novatec Editora, 2016.

NIEDERAUER, Juliano. Desenvolvendo Websites com PHP. São Paulo: Novatec Editora, 2019.

WELLING, Luke; THOMSON, Laura. Desenvolvimento Web com PHP e MySQL. Rio de Janeiro: Alta Books, 2018.

SCHULTZ, Alexandre; SCHULTZ, Fábio. Lógica de Programação e Algoritmos. São Paulo: Bookman, 2019.

Aula 8 — POST (cadastro/login) e validação básica

A Aula 8 é um passo bem importante porque ela coloca o PHP em um cenário muito comum na vida real: quando o usuário envia dados que não devem aparecer na URL. Se na aula anterior você trabalhou com o método GET (ótimo para buscas e filtros), agora entra o POST, que é o formato mais usado para formulários de cadastro, login, envio de mensagens e qualquer situação em que você quer mais privacidade e organização. O POST não é “mágica” nem “segurança total”, mas ele já muda bastante o jeito como os dados circulam: em vez de ficarem visíveis na barra de endereço, eles vão no corpo da requisição.

É útil pensar nisso como duas formas de entregar um recado. No GET, você escreve a mensagem em um bilhete colado do lado de fora da caixa — qualquer pessoa que olhe consegue ler. No POST, você coloca o recado dentro da caixa e fecha. Ainda assim, o caminho importa (por exemplo, usar HTTPS em aplicações reais), mas para o aluno iniciante a grande sacada é: POST é o padrão quando estamos enviando dados de formulário de forma mais “reservada” e estruturada.

Do lado do PHP, a lógica é parecida com a do GET: existe uma “caixinha” pronta esperando os dados do usuário. Só que agora ela se chama $_POST. Quando o formulário é enviado, o PHP recebe os campos e você acessa pelo nome do input. Isso parece simples — e é — mas a Aula 8 traz um ponto que muda o jeito de programar: validação. Porque quando os dados vêm do usuário, eles vêm do mundo real. E o mundo real não é organizado: as pessoas esquecem campos em branco, digitam errado, colam espaços sem querer, usam formatos estranhos e, às vezes, tentam “testar” o sistema.

Por isso, antes de qualquer processamento, a aula costuma

ensinar um ritual básico (e muito saudável): validar antes de confiar. Isso inclui checar se o campo foi enviado e se ele faz sentido. Um nome não pode ser vazio. Um e-mail precisa, no mínimo, parecer um e-mail. Uma senha não deve ser um campo em branco. Uma quantidade não pode ser negativa. Essa etapa é como a triagem de um atendimento: antes de seguir, você confirma se as informações mínimas estão ali.

E aqui entra uma prática que parece pequena, mas muda tudo: usar trim() para remover espaços extras. Muita gente “preenche” um campo com um monte de espaços sem perceber — ou o próprio navegador/teclado acaba colocando espaços no início e no fim. Quando você usa trim(), você limpa esse excesso e evita situações como “o usuário digitou o nome, mas o sistema achou vazio” (ou o contrário: achou válido quando era só espaço). É um cuidado simples e muito comum em projetos reais.

Outra função que aparece nesta aula como uma espécie de “cinto de segurança” é o htmlspecialchars(). Ela ajuda a evitar que o conteúdo digitado pelo usuário seja interpretado como código HTML quando você for exibir de volta na página. Em termos bem humanos: imagine que alguém digite no campo de nome algo estranho e isso “quebre” a forma como sua página aparece. O htmlspecialchars() transforma certos caracteres em versões seguras para exibição. Para quem está começando, a mensagem principal é: se você vai mostrar na tela algo que o usuário digitou, trate esse texto antes. Isso melhora a segurança e também evita dores de cabeça com layout.

A validação de e-mail na Aula 8 costuma ser apresentada de forma simples, porque o objetivo é didático: começar a pensar em regras. Muitos cursos usam a ideia de “tem que ter @” como validação inicial, não porque isso seja perfeito, mas porque ajuda o aluno a treinar a lógica de checagem. E esse é o ponto pedagógico: você está aprendendo a construir critérios. Mais para frente, você pode melhorar a validação com funções mais específicas, mas aqui o essencial é entender como detectar um erro, guardar uma mensagem e impedir o sistema de seguir como se estivesse tudo certo.

E é aí que surge uma habilidade muito importante: mostrar mensagens de erro de forma amigável. Em vez de deixar o sistema falhar ou exibir avisos técnicos, você aprende a dizer ao usuário o que precisa ser corrigido: “O nome é obrigatório”, “Informe um e-mail válido”, “A senha não pode estar vazia”. Essa comunicação é parte da qualidade de um sistema. Um programa bem feito não é só

o sistema falhar ou exibir avisos técnicos, você aprende a dizer ao usuário o que precisa ser corrigido: “O nome é obrigatório”, “Informe um e-mail válido”, “A senha não pode estar vazia”. Essa comunicação é parte da qualidade de um sistema. Um programa bem feito não é só o que calcula certo; é o que orienta a pessoa quando algo está errado. Na prática, isso costuma ser feito acumulando erros (por exemplo, em uma lista/array) e exibindo tudo de uma vez, de forma clara.

Também é nesta aula que o aluno percebe a diferença de experiência entre GET e POST. Com GET, é comum atualizar a página e ver os parâmetros na URL; com POST, atualizar pode gerar aquela mensagem do navegador dizendo que “o formulário será reenviado”. Isso faz parte do comportamento do POST. E, pedagogicamente, é uma ótima oportunidade para reforçar: POST é envio de dados, e o navegador entende que reenviar pode repetir uma ação. Em sistemas reais, isso leva a técnicas como redirecionamento depois do envio, mas no nível básico o objetivo é apenas reconhecer o comportamento e entender por quê.

No final da Aula 8, o aluno deixa de ver formulário como “uma telinha bonitinha” e passa a ver formulário como uma porta de entrada do sistema — e toda porta de entrada precisa de regras. POST é o caminho mais comum para isso. Ele permite que você receba dados sem expor na URL e cria um ambiente natural para treinar validações, limpezas de texto e respostas mais humanas. Quando o aluno termina essa aula, ele já está muito mais perto do cotidiano de quem desenvolve para web: receber dados, validar, tratar e responder com clareza.

Em resumo, a Aula 8 ensina o essencial para lidar com o mundo real: nem todo dado vem perfeito, nem todo usuário preenche certo, e o sistema precisa estar preparado. Aprender POST junto com validação básica é como aprender a dirigir não só em rua vazia, mas com trânsito de verdade: você começa a prever problemas e a construir soluções mais seguras e cuidadosas.

Referências bibliográficas

ALMEIDA, Marco Antonio. PHP: Programando com Orientação a Objetos. São Paulo: Novatec Editora, 2016.

NIEDERAUER, Juliano. Desenvolvendo Websites com PHP. São Paulo: Novatec Editora, 2019.

WELLING, Luke; THOMSON, Laura. Desenvolvimento Web com PHP e MySQL. Rio de Janeiro: Alta Books, 2018.

SCHULTZ, Alexandre; SCHULTZ, Fábio. Lógica de Programação e Algoritmos. São Paulo: Bookman, 2019.

Aula 9 — Integrando tudo: página que processa e responde com clareza

A Aula 9 é como juntar

todas as peças que você veio construindo ao longo do curso e ver o PHP funcionando com “cara de aplicação de verdade”. Até aqui, você aprendeu conceitos importantes separados: variáveis, condições, laços, arrays, funções, GET e POST. Agora o foco é entender o fluxo completo mais comum em páginas web com PHP: mostrar um formulário, receber os dados, validar, processar e devolver uma resposta clara. Parece simples, mas esse roteiro é a espinha dorsal de muitos sistemas, desde um formulário de contato até uma página de pedido ou orçamento.

Um jeito bem didático de enxergar essa aula é pensar em duas fases de uma mesma página. Na primeira fase, o usuário ainda não enviou nada. Então a página precisa ser acolhedora: mostrar o formulário, orientar o preenchimento, deixar claro o que vai acontecer. Na segunda fase, o usuário já enviou os dados. E aí a página troca de postura: ela passa a analisar o que chegou, verificar se está tudo certo e decidir o que mostrar. Essa mudança de “modo” é algo que o PHP faz muito bem, e aprender a reconhecer isso ajuda o aluno a organizar o código com tranquilidade, sem virar um emaranhado.

É aqui que entra uma ideia que parece pequena, mas é muito importante: separar lógica de exibição, mesmo que seja de forma simples. Você não precisa criar uma arquitetura complexa para isso; basta ter um pedaço do código responsável por coletar e validar os dados, e outro pedaço responsável por exibir o resultado. Quando tudo fica misturado — validação no meio do HTML, cálculos espalhados e mensagens soltas — o projeto começa a ficar difícil de manter. Na Aula 9, o aluno aprende que um código limpo não é “frescura”; é uma forma de se proteger da confusão quando o projeto cresce.

Outro aprendizado forte dessa aula é sobre mensagens. Uma aplicação bem feita não apenas calcula; ela conversa. Se o usuário esqueceu um campo, você não precisa assustá-lo com um erro técnico. Você mostra uma mensagem amigável, direta e específica: “Informe a quantidade”, “O nome é obrigatório”, “Selecione um produto válido”. E, quando está tudo certo, a página também precisa ser clara: mostrar um resumo do que foi enviado, o total calculado, as regras aplicadas (desconto, cupom, frete) e um fechamento humano do tipo “Pedido recebido!” ou “Orçamento gerado com sucesso!”. Essa qualidade da resposta é parte do que diferencia um exercício de aula de uma experiência real.

Nessa fase de integração, as validações ganham um sentido ainda maior. Não é só “validar por

validar”, é garantir que o processamento não vai gerar resultado errado. Por exemplo, se a quantidade vier vazia ou zero, um orçamento pode ficar sem sentido; se o produto não for escolhido corretamente, o cálculo pode usar preço errado; se o cupom vier com espaços extras, pode não ser reconhecido. Por isso, a Aula 9 reforça aquele cuidado com limpeza básica (trim) e com exibição segura de dados digitados pelo usuário (htmlspecialchars). O aluno começa a entender que o melhor momento para evitar problemas é antes de eles virarem problema.

Um ponto muito interessante aqui é a organização do fluxo dentro do código. Uma estrutura bem comum (e bem didática) é: primeiro checar se houve envio do formulário; depois coletar os dados; depois validar; depois processar; e só então exibir o resultado. Quando o aluno segue esse roteiro, ele percebe que as páginas ficam mais previsíveis. E previsibilidade é tudo: você sabe o que acontece em cada etapa e consegue encontrar erros mais rápido. Quando algo dá errado, você sabe se o problema está na coleta, na validação ou no cálculo — e não em “algum lugar no meio”.

A Aula 9 também costuma conversar sobre a diferença entre fazer tudo em um arquivo e dividir em dois. Em projetos pequenos e didáticos, manter o formulário e o processamento no mesmo arquivo é prático e facilita o aprendizado. Já em projetos maiores, separar em um arquivo para exibir e outro para processar pode deixar tudo mais organizado. O mais importante, neste ponto do curso, não é escolher a “arquitetura perfeita”, e sim aprender o raciocínio: o sistema precisa ter um começo (entrada), um meio (processamento) e um fim (saída). Quando essa lógica fica clara, você consegue se adaptar a qualquer estrutura depois.

Uma atividade típica dessa aula — como um formulário de orçamento com produto, quantidade e cupom opcional — é excelente porque parece muito com o que um sistema real faz. Você tem uma lista de produtos com preços (array), escolhe um, informa quantidade, talvez aplica um cupom, e no final recebe um resumo com total e desconto. Esse exercício usa quase tudo: arrays para catálogo, if/else para regras, funções para cálculos, POST para envio e validação para garantir consistência. E o aluno sente que está construindo algo “de verdade”, não apenas testando comandos isolados.

No fim, a Aula 9 deixa uma mensagem bem importante: programar para web é criar um ciclo de interação. O usuário envia dados, o sistema trata com cuidado e devolve uma resposta

útil. Quando você aprende esse ciclo, você aprende o básico de uma aplicação web. Daqui para frente, o que muda são as camadas: banco de dados, autenticação, sessões, segurança mais robusta, organização em arquivos e frameworks. Mas o coração continua o mesmo que você praticou aqui: entrada, validação, processamento e saída.

Em resumo, a Aula 9 é a aula da “costura”. Ela pega tudo o que você aprendeu e mostra como construir uma página completa, com começo, meio e fim, de um jeito claro e humano. O aluno sai com uma visão mais madura: não basta rodar código, é preciso estruturar o caminho que o usuário percorre. E quando você aprende a fazer isso bem, você deixa de criar páginas soltas e começa a criar experiências — mesmo que simples — que já se comportam como um sistema.

Referências bibliográficas

ALMEIDA, Marco Antonio. PHP: Programando com Orientação a Objetos. São Paulo: Novatec Editora, 2016.

NIEDERAUER, Juliano. Desenvolvendo Websites com PHP. São Paulo: Novatec Editora, 2019.

WELLING, Luke; THOMSON, Laura. Desenvolvimento Web com PHP e MySQL. Rio de Janeiro: Alta Books, 2018.

SCHULTZ, Alexandre; SCHULTZ, Fábio. Lógica de Programação e Algoritmos. São Paulo: Bookman, 2019.

Estudo de caso do Módulo 3: “Pedidos da Lanchonete Sabor & Prosa — quando o formulário vira confusão”

A lanchonete Sabor & Prosa decidiu facilitar a vida: criar uma página simples para receber pedidos pelo site. Nada de app, nada de banco de dados por enquanto — só um formulário bem feito que permita ao cliente escolher o lanche, informar a quantidade e mandar observações. O dono, o Tião, quer algo direto: “o cliente preenche, o site calcula o total e mostra um resumo do pedido”.

Você, como aluno do curso, pega essa missão. E é aí que o Módulo 3 entra com força: GET (Aula 7), POST e validação (Aula 8), e integração do fluxo completo (Aula 9). Só que, ao colocar isso de pé, aparecem os erros clássicos que fazem o sistema parecer “assombrado”: às vezes dá certo, às vezes dá errado, às vezes a página mostra coisas estranhas. Vamos acompanhar.

O objetivo do sistema (simples e real)

O formulário precisa receber:

• Nome do cliente (obrigatório)
• Produto (obrigatório, escolhido de uma lista)
• Quantidade (obrigatório, > 0)
• Observações (opcional)

E no final exibir:

• Resumo do pedido
• Total calculado
• Mensagens de erro amigáveis (quando houver)

Cena 1 — “Usei GET no login… e agora a senha aparece na URL”

No primeiro teste, o aluno coloca tudo em GET porque “funcionou na

primeiro teste, o aluno coloca tudo em GET porque “funcionou na aula 7”. A página fica assim:
/pedido.php?nome=ana&senha=123&produto=x...

Erro comum

• Usar GET para dados sensíveis (login, cadastro com dados pessoais, etc.).

Por que é um problema

• O dado aparece na URL, pode ficar salvo no histórico e ser copiado sem querer.

Como evitar

• Para formulários de pedido/cadastro/login, usar POST.
• Deixar GET para busca e filtros (coisas “compartilháveis”).

Cena 2 — “Undefined index: nome” (o erro que assusta iniciantes)

O aluno tenta ler $_POST['nome'] logo de cara. Só que, quando a página abre pela primeira vez (sem envio), dá aviso porque nome ainda não existe.

Erro comum

• Acessar $_GET/$_POST sem checar se o formulário foi enviado.

Como evitar

• Verificar se o dado existe antes:
• checar se o request veio com envio (ou se a chave existe)
• Organizar a página em dois “momentos”:

1.                                                                                                                                                                                                                    mostrar formulário (antes do envio)

2.                                                                                                                                                                                                                    processar e mostrar resultado (depois do envio)

Dica mental

• “Se o usuário ainda não enviou, não existe dado pra ler.”

Cena 3 — “O campo está preenchido…, mas o sistema diz que está vazio”

O cliente digita o nome com espaços: " Ana ". O sistema acusa “Nome obrigatório”.

Erro comum

• Validar sem limpar espaços.

Como evitar

• Usar trim() nos textos antes de validar:
• assim “só espaços” vira vazio de verdade
• e texto com espaços extras vira texto limpo

Bônus de qualidade

• Você melhora a experiência do usuário sem ele nem perceber.

Cena 4 — “O cliente digitou 0 e o pedido foi aceito”

O aluno valida quantidade apenas verificando se “existe”. A pessoa envia 0 ou -2 e o cálculo fica sem sentido.

Erros comuns

• Não validar faixa numérica (apenas presença)
• Confiar que o usuário vai se comportar “certinho”

Como evitar

• Validar regras do mundo real:
• quantidade precisa ser número
• precisa ser maior que zero

Regra de ouro

• Presença ≠ validade. O campo pode existir e ainda assim estar errado.

Cena 5 — “O cliente escolheu um produto que não existe”

O formulário tem

formulário tem uma lista (ex.: Hambúrguer, Suco, Batata). Mas alguém manipula o HTML ou envia um valor diferente.

Erro comum

• Confiar 100% no que veio do formulário.

Como evitar

• Validar se o produto recebido está dentro da lista permitida.
• Manter um “catálogo” no código (array) e checar se o item existe nele.

Resumo

• O usuário pode alterar o que é enviado. O servidor precisa confirmar.

Cena 6 — “A página ficou toda torta depois que alguém escreveu observação esquisita”

Um cliente escreve algo como <b>SEM CEBOLA</b> ou até insere caracteres que bagunçam a tela. Quando você imprime direto, o navegador interpreta como HTML.

Erro comum

• Exibir na tela texto vindo do usuário sem tratar.

Como evitar

• Antes de exibir, higienizar:
• htmlspecialchars() impede que texto do usuário vire HTML na sua página

Mentalidade

• “Tudo que vem do usuário é texto comum, não instrução para o navegador.”

Cena 7 — “Cliquei atualizar e o pedido duplicou”

O aluno usa POST e, após enviar, aperta F5 para atualizar. O navegador pergunta se quer reenviar. Ao confirmar, o “pedido” é processado de novo.

Erro comum

• Não lidar com o comportamento do POST ao atualizar a página.

Como evitar (nível didático, sem complicar demais)

• Mostrar uma mensagem clara após processar: “Pedido processado. Evite atualizar para não reenviar.”
• (Em aplicações reais) usar o padrão de redirecionamento após POST para evitar reenvio.

Importante

• O aluno não precisa dominar arquitetura aqui, só entender o comportamento e como prevenir confusão.

Como o sistema ficou estável e “com cara de real”

Depois de apanhar um pouco (normal), o aluno reorganiza o projeto com um fluxo limpo:

1.     Exibe o formulário

2.     Ao enviar (POST), coleta os dados

3.     Limpa os textos (trim)

4.     Valida (obrigatórios, números, produto existente)

5.     Se houver erros, mostra todos de uma vez, com linguagem amigável

6.     Se estiver tudo ok:

o    calcula total

o    mostra resumo do pedido

o    exibe observação com segurança (htmlspecialchars)

Resultado: o cliente entende, o sistema não quebra e você ganha confiança.

Checklist rápido: erros mais comuns do Módulo 3 (e o antídoto)

• Usar GET para dados sensíveis → use POST
• Ler $_POST sem checar envio → use isset/fluxo “antes/depois”
• Validar sem trim() → limpe antes de validar
• Aceitar quantidade 0 ou negativa → valide regra (> 0)
• Confiar no produto recebido → valide contra lista permitida

• Exibir texto do usuário sem tratar → use htmlspecialchars
• Atualizar e reenviar POST sem perceber → orientar e (em real) redirecionar

Parte inferior do formulário