Jump to content
Sign in to follow this  
bioshock

Boa prática (PHP)

Recommended Posts

bioshock

Viva povo.

Tenho lido imensos artigos e tutoriais onde os mesmos referem algumas "supostas" boas práticas de programação em PHP. A começar por "cada macaco no seu galho", ou seja, PHP é PHP, HTML é HTML e CSS é CSS, portanto, 3 ficheiros independentes.

Quero com isto dizer que num ficheiro de PHP só contém PHP e não HTML/CSS.

No entanto, eu preciso(?) de criar a página main (index.php) para chamar os meus includes e afins.

Que regras, desde logo, estipulam nos vossos projectos?

Share this post


Link to post
Share on other sites
Warrior

Separar o PHP do HTML é normalmente o maior problema porque as coisas parecem "coladas".

Talvez devesses dar uma vista de olhos num sistema de templates, que te obriga a separar os macacos. O mais conhecido e usado é provavelmente o smarty: http://www.smarty.net/

Share this post


Link to post
Share on other sites
mjamado
A começar por "cada macaco no seu galho", ou seja, PHP é PHP, HTML é HTML e CSS é CSS, portanto, 3 ficheiros independentes.

Na realidade, são bastante mais do 3. Para um exemplo muito simplista como o que deste, vamos assumir que seria um canal de notícias, terias, pelo menos, quatro ficheiros:

  • a CSS necessária;
  • uma classe do modelo de dados, responsável, entre outras coisas, pelas queries à BD;
  • uma classe, ou ficheiro "avulso" do controlador, responsável pela gestão dos pedidos, verificação de autenticação e autorização e organização dos dados pedidos ao modelo;
  • um ficheiro com o HTML e o PHP estritamente necessário para a apresentação (ciclos, formatações de números e datas, por aí). Alternativamente, este ficheiro poderia ser numa linguagem de templating: eu uso o Smarty, mas sei que anda por aí pessoal no fórum que usa o Mustache - e há outros;

Fora todas os outros ficheiros necessários, claro, como gestão de ligação à BD, gestão de ficheiros (uploads/downloads), classes estáticas com ferramentas comuns, etc. Mais opções de templating que se podem tomar (zonas "comuns" dos site - cabeçalho, título, rodapé, barras laterias - em templates separados).


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
taviroquai

Junta a isso ficheiros com strings para i18n se precisar de ter o site em várias linguas...

E junta ficheiros javascript se precisar de uma interface viva...

Por vezes as configurações surgem em ficheiros xml...

Antes de escrever código, na análise, UML...

Ficheiros SQL para o schema dos dados (se se usar uma RDBMS) da aplicação...

Ou seja, uma aplicação em php feita de raiz pode usar UML, SQL, PHP, XML (e alikes), INI, HTML, CSS, JS... tudo separado...

Share this post


Link to post
Share on other sites
bioshock

Separar o PHP do HTML é normalmente o maior problema porque as coisas parecem "coladas".

E não estão? De certa forma, parece-me que não há problema em juntar o PHP com HTML, mas a questão da organização é um ponto essencial.

Na realidade, são bastante mais do 3. Para um exemplo muito simplista como o que deste, vamos assumir que seria um canal de notícias, terias, pelo menos, quatro ficheiros:

  • a CSS necessária;
  • uma classe do modelo de dados, responsável, entre outras coisas, pelas queries à BD;
  • uma classe, ou ficheiro "avulso" do controlador, responsável pela gestão dos pedidos, verificação de autenticação e autorização e organização dos dados pedidos ao modelo;
  • um ficheiro com o HTML e o PHP estritamente necessário para a apresentação (ciclos, formatações de números e datas, por aí). Alternativamente, este ficheiro poderia ser numa linguagem de templating: eu uso o Smarty, mas sei que anda por aí pessoal no fórum que usa o Mustache - e há outros;

Mas toda essa lista, referes-te a ficheiros à parte que são chamados em determinadas páginas?

Fora todas os outros ficheiros necessários, claro, como gestão de ligação à BD, gestão de ficheiros (uploads/downloads), classes estáticas com ferramentas comuns, etc. Mais opções de templating que se podem tomar (zonas "comuns" dos site - cabeçalho, título, rodapé, barras laterias - em templates separados).

Bem, tudo o que enumeraste foram os meus problemas ao longo da minha aprendizagem com o PHP, não cumpri nenhuma regra. Copiava os códigos de umas páginas para as outras para criar o layout, não tinha sequer CSS, aliás, tinha mas era o dreamweaver(:) ) que o auto-gerava. É por isso que agora me vejo à rasca e ando a enfardar com manuais para ver se aprendo correctamente. 😳

Ou seja, uma aplicação em php feita de raiz pode usar UML, SQL, PHP, XML (e alikes), INI, HTML, CSS, JS... tudo separado...

Eu não posso aprender tudo ao mesmo tempo, ou até posso, mas não me facilita a vida.

Não pretendo ter quaisquer efeitos (de animação) num projecto inicial. Quando concluir um projecto ao meu gosto e com HTML, CSS & PHP então aí acho que posso partir para a aprendizagem de jQuery e afins. Acho, verdadeiramente, que se deve seguir uma ordem, algo como: html > css > linguagem > "extras".

Relativamente às SGDBs é um dos pontos onde estou mais à vontade.

Outra questão que já vi ser colocada muitas vezes é sobre as frameworks. Pelo que li, as frameworks não são mais do que ficheiros.php que contêm grande parte das tarefas que quase todos os sites possuem e que facilitam a vida ao programador. Ok, até aqui tudo bem, mas não me parece que alguém que tenha poucos conhecimentos (como por exemplo eu) se deva aventurar por aí, pois acho que perde um pouco do estudo fundamental. O que vos parece?

Share this post


Link to post
Share on other sites
mjamado
E não estão? De certa forma, parece-me que não há problema em juntar o PHP com HTML, mas a questão da organização é um ponto essencial.

Existe uma longa e exaustiva discussão de ambos os lados - os que defendem o uso de uma linguagem de templating, argumentando com a encapsulação e limpeza, e os que defendem o uso de PHP "puro" para o mesmo efeito, argumentando com uma maior velocidade de execução (as linguagens de templating têm de ser interpretadas) e com uma menor complexidade operacional. Só tu podes escolher um destes caminhos, mas vais sempre ouvir alguém dizer que pelo outro é melhor.

Mas toda essa lista, referes-te a ficheiros à parte que são chamados em determinadas páginas?

Em teoria, todos os canais de teu site terão, pelo menos, um controlador e um ou mais templates; a maioria dos canais terá, também, um modelo (uma homepage, por exemplo, raramente tem modelo - usa os modelos dos outros canais para sumarizar informação na página principal). O que quer dizer que um site completo terá dezenas de ficheiros PHP. Repara que isto corresponde ao paradigma MVC; apesar de ser largamente aceite hoje em dia, quase padronizado, existem outros paradigmas. Existe, inclusivamente, quem não use paradigma nenhum... e defenda isso!

Eu não posso aprender tudo ao mesmo tempo, ou até posso, mas não me facilita a vida.

Ninguém aprende tudo ao mesmo tempo e, sobretudo, ninguém sabe tudo sobre uma dada coisa. É loucura tentar decorar mais do que uma centena de funções PHP; para isso é que existe a documentação, basta teres a noção de quais as áreas cobertas, e ires à procura daquela função ou classe obscura, quando precisares dela.

Outra questão que já vi ser colocada muitas vezes é sobre as frameworks. Pelo que li, as frameworks não são mais do que ficheiros.php que contêm grande parte das tarefas que quase todos os sites possuem e que facilitam a vida ao programador. Ok, até aqui tudo bem, mas não me parece que alguém que tenha poucos conhecimentos (como por exemplo eu) se deva aventurar por aí, pois acho que perde um pouco do estudo fundamental. O que vos parece?

Como já defendi tantas vezes aqui no fórum, só se deve usar uma framework ou uma CMS - em especial estas últimas - quando tivermos sido capazes de fazer a nossa. Só neste ponto conseguimos analisar as opções e tomar uma decisão em consciência do que acarreta.

Por isso, sim, tenta aplicar todos os conhecimentos e melhores práticas que aprenderes agora para fazer as coisas correctamente e tenta fazer uma framework tua que funcione, lança três ou quatro sites, no mínimo, que a use, e depois decide se queres continuar a melhorá-la ou se queres mudar para uma das que para aí andam.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
Warrior

Eu não iria tão longe ao dizer que deves fazer a tua própria framework, mas concordo que só deves utilizar uma quando souberes responder sozinho à questão "deveria estar a usar uma framework?". Com isto quero dizer que é necessário conhecimento extra para se usar realmente a framework, e não ser simplesmente um limitador.

Share this post


Link to post
Share on other sites
bioshock

(...), e os que defendem o uso de PHP "puro" para o mesmo efeito, argumentando com uma maior velocidade de execução (as linguagens de templating têm de ser interpretadas) e com uma menor complexidade operacional.

Se percebi, o uso de PHP "puro" é a criação de tudo em .php? (ex:)

echo '<table>';

Neste caso é utilizado o PHP junto com html.

Como já defendi tantas vezes aqui no fórum, só se deve usar uma framework ou uma CMS - em especial estas últimas - quando tivermos sido capazes de fazer a nossa. Só neste ponto conseguimos analisar as opções e tomar uma decisão em consciência do que acarreta.

Eu não iria tão longe ao dizer que deves fazer a tua própria framework, mas concordo que só deves utilizar uma quando souberes responder sozinho à questão "deveria estar a usar uma framework?". Com isto quero dizer que é necessário conhecimento extra para se usar realmente a framework, e não ser simplesmente um limitador.

Acho que esse ponto está arrumado. Frameworks só com um relativo "à vontade".

Uma das coisas que tive conhecimento, recentemente e precisamente, foi sobre o SQL Injection. Existem variados tutoriais sobre como proceder para a segurança do site contra o ataque de exploits, mas entre os que li, este, que até está na nossa wiki, pareceu-me bastante simples, esclarecedor e seguro.

Existem assim tantos ataques? Mesmo eu mandando para o url: pagina.php?email=olhaEle@gmail.com

É possível haver SQL Injection? E se o site não possuir extensão em nenhuma página?

Share this post


Link to post
Share on other sites
mjamado

Se percebi, o uso de PHP "puro" é a criação de tudo em .php? (ex:)

echo '<table>';

Neste caso é utilizado o PHP junto com html.

Sim, e não. Esse tipo de echo, só quando tem mesmo que ser, por alguma razão bizarra... O PHP "puro" que eu falava é deste estilo:

<html ...>
<head>
  <title><?php echo $tituloDaPagina; ?></title>
</head>
<body>
  <?php foreach(&noticias as $noticia): ?>
  <h1><?php echo $noticia['titulo']; ?></h1>
  <img src="/imagens/<?php echo $noticia['img_1_src']; ?>" alt="<?php echo $noticia['img_1_alt']; ?>" />
  <div class="resumo"><?php echo $noticia['resumo']; ?></div>
  <hr />
  <?php endforeach; ?>
</body>
</html>

Existem assim tantos ataques? Mesmo eu mandando para o url: pagina.php?email=olhaEle@gmail.com

É possível haver SQL Injection? E se o site não possuir extensão em nenhuma página?

Sim, existem, e é um perigo bastante real: SQL injection, PHP injection e cross-site scripting são preocupações a ter sempre! Os dois primeiros colocam em risco a tua aplicação e/ou a tua máquina, o último coloca em risco os teus utilizadores.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
bioshock

As linhas de código que colocaste percebem-se, mas fico com a sensação que o código fica um pouco ou nada desorganizado/não tão explícito.

Relativamente ao SQL Injection e afins, o link que coloquei que está no P@P é aconselhável? Pareceu-me sinceramente uma boa proposta a por em prática.

A função require() mantém o ficheiro sempre activo, mesmo quando há uma mudança de página? (Sei que também existe o require_once(), daí a minha dúvida)

O que eu fazia para me ligar à base de dados, era usar um ficheiro .inc (include) e chamá-lo em todas as páginas, parece-me desnecessário caso o require() does the job :)

Até que ponto é aconselhável mostrar explicitamente a quantidade de utilizadores já registados na nossa página? Até que ponto isso não pode desmoralizar a inscrição?

Share this post


Link to post
Share on other sites
mjamado

As linhas de código que colocaste percebem-se, mas fico com a sensação que o código fica um pouco ou nada desorganizado/não tão explícito.

Menos que aquilo, é impossível. Mesmo com uma linguagem de templating, a quantidade de código é sensivelmente a mesma.

Relativamente ao SQL Injection e afins, o link que coloquei que está no P@P é aconselhável? Pareceu-me sinceramente uma boa proposta a por em prática.

O que está na wiki (foi o link que colocaste antes, certo?) não é SQLi, mas sim PHPi. E é curto, muito curto. Seja como for, se usares prepared statments (e devias), não tens que te preocupar com SQLi, mas apenas com PHPi e XSS.

A função require() mantém o ficheiro sempre activo, mesmo quando há uma mudança de página? (Sei que também existe o require_once(), daí a minha dúvida)

O que eu fazia para me ligar à base de dados, era usar um ficheiro .inc (include) e chamá-lo em todas as páginas, parece-me desnecessário caso o require() does the job :)

Cada request tem que re-incluir todos os ficheiros necessários - se mudas de página, tens que o fazer. Expliquei muito recentemente aqui no fórum a diferença entre o require e o include. As variantes *_once apenas impedem que seja incluído mais do que uma vez por request.

Até que ponto é aconselhável mostrar explicitamente a quantidade de utilizadores já registados na nossa página? Até que ponto isso não pode desmoralizar a inscrição?

Isso já não tem nada que ver com programação, mas sim com opções de negócio e/ou de design. Dum ponto de vista sociológico, teres uma caixa brilhante com algo como "200 pessoas já aderiram! Adira também!", despoleta duas acções: a necessidade de agir (pela intensidade da ordem) e o efeito de "matilha" ("uau, bué pessoas aderiram, vou aderir para também ser cool"). Isto está estudado, e, normalmente, é boa opção. Results may vary.

P.S.: diferença entre require e include.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
bioshock

Menos que aquilo, é impossível. Mesmo com uma linguagem de templating, a quantidade de código é sensivelmente a mesma.

Eu referia-me a fazer algo deste género:

<?php
    echo "<textarea name='mydata'>\n";
    echo htmlspecialchars($data)."\n";
    echo "</textarea>";
?>

Ou seja, todo o código HTML é criado via PHP. Bad practice? 🤔

O que está na wiki (foi o link que colocaste antes, certo?) não é SQLi, mas sim PHPi. E é curto, muito curto. Seja como for, se usares prepared statments (e devias), não tens que te preocupar com SQLi, mas apenas com PHPi e XSS.

Sim, foi o link que coloquei. Bem, eu fui dar uma espreitadela nos Prepared Statements do Manual PHP e, se bem percebi, o objectivo passa por criar parâmetros para definir os valores da query.

Em .NET podemos fazer destas maneiras:

1.

Dim Sql As String = "INSERT INTO Tabela (Nome, Distrito) VALUES ('" & TextBox1.Text & "','" & TextBox1.Text & "')"

- Que, segundo o manual, não é a forma correcta, visto que, caso hajam múltiplas inserções pode haver um delay no processamento da informação.

2.

Dim Sql As String = "INSERT INTO Tabela (Nome, Distrito) VALUES (@Nome, @Distrito)"
Dim SqlCommand As New SqlCommand(Sql, Connection)
SqlCommand.Parameters.Add("@Nome", Varchar).Value = Textbox1.Text
SqlCommand.Parameters.Add("@Distrito", Varchar).Value = Textbox2.Text

- Que, segundo o manual, é a forma correcta, e o mais importante: evita o SQLi.

If an application exclusively uses prepared statements, the developer can be sure that no SQL injection will occur.

Menos um problema para me preocupar :P

Enquanto googlava por SQLi, encontrei este link, onde, basicamente, o rapaz que escreveu aquilo diz como o processo é feito para usufruir do injection. Contudo, o que gostava de saber era se, caso a página em questão, não mostrar os seus "subs-urls" like: www.urlXpto.com/products/ - e não www.urlXpto.com/products/view_product.php?id=3 - continua a ser possível haver SQLi?

Cada request tem que re-incluir todos os ficheiros necessários - se mudas de página, tens que o fazer. Expliquei muito recentemente aqui no fórum a diferença entre o require e o include. As variantes *_once apenas impedem que seja incluído mais do que uma vez por request.

Mas o request deve ser iniciado só uma vez ou sempre que seja necessário? Por exemplo a base de dados. Devo chamar a ligação sempre que preciso de executar parâmetros ou assim que é feito o load() da página?

Isso já não tem nada que ver com programação, mas sim com opções de negócio e/ou de design. Dum ponto de vista sociológico, teres uma caixa brilhante com algo como "200 pessoas já aderiram! Adira também!", despoleta duas acções: a necessidade de agir (pela intensidade da ordem) e o efeito de "matilha" ("uau, bué pessoas aderiram, vou aderir para também ser cool"). Isto está estudado, e, normalmente, é boa opção. Results may vary.

Correcto, mas se estiver lá a dizer "5 utilizadores já aderiram" não me parece que vá despoletar grande acção  :)

Share this post


Link to post
Share on other sites
mjamado

Eu referia-me a fazer algo deste género:

<?php
    echo "<textarea name='mydata'>\n";
    echo htmlspecialchars($data)."\n";
    echo "</textarea>";
?>

Ou seja, todo o código HTML é criado via PHP. Bad practice? 🤔

O  conceito de bad prectice é para "pinceladas" mais largas. Isso é um detalhe, que varia de dev para dev. Se achas que te dá mais jeito a ti, força. Pessoalmente, prefiro doutra maneira:

<textarea name='mydata'>
  <?php echo htmlspecialchars($data); ?>
</textarea>

Repara que é menos código, e fica mais limpo. Mas vai dar ao mesmo.

Sim, foi o link que coloquei. Bem, eu fui dar uma espreitadela nos Prepared Statements do Manual PHP e, se bem percebi, o objectivo passa por criar parâmetros para definir os valores da query.

(...)

- Que, segundo o manual, é a forma correcta, e o mais importante: evita o SQLi.Menos um problema para me preocupar :P

Pronto, em PHP é igual. Se usares prepared statements, estás automaticamente a salvo de SQLi.

Contudo, o que gostava de saber era se, caso a página em questão, não mostrar os seus "subs-urls" like: www.urlXpto.com/products/ - e não www.urlXpto.com/products/view_product.php?id=3 - continua a ser possível haver SQLi?

Sim, continua. Para cada URL "bonito" continua a existir um URL com query string, para onde é redireccionado o pedido. Só dá um bocadinho mais trabalho ao hacker. Mas, reafirmo, começa a usar prepared statments e não te preocupes mais com SQLi.

Mas o request deve ser iniciado só uma vez ou sempre que seja necessário? Por exemplo a base de dados. Devo chamar a ligação sempre que preciso de executar parâmetros ou assim que é feito o load() da página?

Um request é um pedido do browser, sempre que muda de página (ou uma chamada AJAX, que é a mesma coisa). Dependendo de como implementares a tua classe de BD, podes chamar apenas uma vez, e ficas responsável por carregar a variável atrás de ti de ficheiro para ficheiro onde precises dela, ou chamá-la quantas vezes for necessário, em todos os ficheiros necessários. Esta última opção fica mais segura ao nível dos bugs - tens sempre a certeza que o objecto da BD está disponível - mas tens que fazer a classe na forma de singleton, para não teres 10 objectos diferentes de BD no final de passares por 10 ficheiros.

Correcto, mas se estiver lá a dizer "5 utilizadores já aderiram" não me parece que vá despoletar grande acção  :)

Alguma vez alguém terá que aderir... :P Se tiveres lá a call to action, podes apresentar o número de pessoas que já aderiram só acima de um certo patamar. Se googlares "design call to action" vais apanhar gente a falar disto, quase de certeza.


"Para desenhar um website, não tenho que saber distinguir server-side de client-side" - um membro do fórum que se auto-intitula webdesigner. Temo pelo futuro da web.

Share this post


Link to post
Share on other sites
bioshock

<textarea name='mydata'>
  <?php echo htmlspecialchars($data); ?>
</textarea>

Bem, até pareceu mais arrumadinho. Mas no código que colocaste lá em cima, já não gostei tanto.

Mas se vai dar ao mesmo, não há com que preocupar.

Pronto, em PHP é igual. Se usares prepared statements, estás automaticamente a salvo de SQLi.

:P

(...) Dependendo de como implementares a tua classe de BD, podes chamar apenas uma vez, e ficas responsável por carregar a variável atrás de ti de ficheiro para ficheiro onde precises dela, ou chamá-la quantas vezes for necessário, em todos os ficheiros necessários.

Prefiro a segunda opção. Assim saberei sempre quando a ligação está ou não activa.

Alguma vez alguém terá que aderir... :) Se tiveres lá a call to action, podes apresentar o número de pessoas que já aderiram só acima de um certo patamar. Se googlares "design call to action" vais apanhar gente a falar disto, quase de certeza.

Estive a procurar e o conceito abrange não só o exemplo que dei. Muito bom!

Relativamente à estrutura do site, o aconselhável é desenvolver tudo via CSS e chamar as imagens que forem necessárias ao preenchimento da página, ou desenvolver o layout em .PSD(mais propriamente dito) e colá-lo, de certa forma, na página e ajustar os objectos aonde se deseja?

Share this post


Link to post
Share on other sites
yoda

Outra questão que já vi ser colocada muitas vezes é sobre as frameworks. Pelo que li, as frameworks não são mais do que ficheiros.php que contêm grande parte das tarefas que quase todos os sites possuem e que facilitam a vida ao programador. Ok, até aqui tudo bem, mas não me parece que alguém que tenha poucos conhecimentos (como por exemplo eu) se deva aventurar por aí, pois acho que perde um pouco do estudo fundamental. O que vos parece?

Perdes muito mais ao usar um CMS do que uma framework.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.