Ir para conteúdo

Arquivado

Este tópico foi arquivado e está fechado para novas respostas.

DougCoder

PHP Orientado Objeto e Procedural (migração, MVC, informações, ideia)

Recommended Posts

Bom dia a todos,

 

Tenho um projeto atualmente zero orientado a objeto. Estava dando uma lida e pesquisada pela net, muita gente diz que o PHP é muito "misto", praticamente todos projetos irá encontrar linguagem procedural a grosso modo como também linguagem orientada a objeto (juntas), principalmente se for algo pequeno que não utilize frameworks como zend, cake, etc.

 

Também ciente que orientação a objeto é um paradigma para nosso código se tornar "algo real", já li até mesmo que não é necessário o código ser baseado em classes para ser orientado a objeto(nunca vi POO sem classes), achei estranho e comecei a duvidar do que estava lendo, onde também dizia que Orientação a Objeto é mais a parte de organização do nosso código e algumas medidas que são padrões para manter essa organização.

 

OK, até ai tudo é teoria.

 

DÚVIDAS QUE NÃO ME DEIXAM DORMIR:

• MVC: É possível eu seguir a estrutura MVC em php para um código não orientado a objeto? É possível ter o MVC em algo mais procedural ou misto?

• MIGRAÇÃO: Caso eu seja obrigado a refazer meu projeto orientado a objeto, o que eu preciso saber que irei encarar pela frente? É algo que leva tempo, mas existe alguma forma de tornar essa migração facilitada?

• PDO / MySQLi: PDO é um método montado em cima do paradigma orientado a objeto, sendo assim posso dizer que PDO é orientado a objeto? Minhas manipulações sql/php com pdo são orientadas a objetos apenas por utilizá-lo? O mesmo para MySQLi.

 

OBS: Boatos de que BOA PARTE da documentação do PHP é estrutural, isto é por si verdade ou não, tudo que existe em PHP estruturado/procedural também existe em PHP orientado a objeto?

 

Eu consigo argumentar para uma banca examinadora de TFC que meu projeto não foi desenvolvido orientado a objeto por algum bom motivo (igual este da documentação se for verdade)?

 

Eu realizei testes de software (funcional/unitário com badboy e análise estática com rips) incrivelmente consegui zerar as falhas de sql injection, session e banco e quase zerar os erros de cross-scripting. Não consegui resolver file manipulation e alguns cross-scripting que quando apliquei a correção com htmlentities deu alguns bug na página.

 

Enfim, com os testes de software consigo "provar", ou melhor, argumentar que minha gambiarra é funcional !!! Porém agora estou preso no MVC/Orientação a Objeto.

 

O que vocês podem me ajudar nesse conceito galera? Estou fudido e tenho que desenvolver orientado a objeto ou existe uma saída? rsrs

Compartilhar este post


Link para o post
Compartilhar em outros sites

É importante entender que, no final das contas, a teoria é diferente da prática.

 

Tenho um projeto atualmente zero orientado a objeto. Estava dando uma lida e pesquisada pela net, muita gente diz que o PHP é muito "misto", praticamente todos projetos irá encontrar linguagem procedural a grosso modo como também linguagem orientada a objeto (juntas) [...]

O PHP, no geral, permite ambos os paradigmas. Foi inicialmente uma linguagem de scripts que evoluiu para uma linguagem dinâmica orientada à objetos.

 

[...] principalmente se for algo pequeno que não utilize frameworks como zend, cake, etc.

Não necessariamente. O framework é uma ferramenta de trabalho para facilitar o desenvolvimento, utilizá-la corretamente é outra história. Assim como trabalhos pequenos (estou falando de qualquer trabalho em qualquer profissão), existem pessoas que quase não utilizam ferramentas, e fazem um trabalho exemplar, e outras que utilizam um grande conjunto de ferramentas (como um framework) e deixam a desejar.

 

Também ciente que orientação a objeto é um paradigma para nosso código se tornar "algo real", já li até mesmo que não é necessário o código ser baseado em classes para ser orientado a objeto(nunca vi POO sem classes), achei estranho e comecei a duvidar do que estava lendo, onde também dizia que Orientação a Objeto é mais a parte de organização do nosso código e algumas medidas que são padrões para manter essa organização.

O conceito de orientação à objetos sem classes existe apenas quando o assunto for somente reutilização de código (que é apenas uma parte da POO).

 

A reutilização, no seu âmbito mais simplista, ocorre através das funções. Agora, a POO, como já falaste, é um paradigma com objetivo de deixar o seu código, e a forma de programar/pensar, o mais próximo possível do mundo real.

 

Em questões de organização, você poderá ter o mesmo nível de organização tanto procedural quanto POO, não é um paradigma que irá definir, previamente, qual será mais organizado.

 

MVC: É possível eu seguir a estrutura MVC em php para um código não orientado a objeto? É possível ter o MVC em algo mais procedural ou misto?nipulações sql/php com pdo são orientadas a objetos apenas por utilizá-lo? O mesmo para MySQLi.

Seguindo a risca o que diz o MVC, e considerando a teoria, é possível. O MVC define uma estruturação em três camadas, com o foco principal na view. Como as camadas são estruturadas, fica conforme o custo x benefício.

 

Se for pensar em questões históricas, o MVC teve sua composição através das classes do Smaltalk. Mas, apenas utilizar classes, não significa ser POO.

 

Veja bem, conforme a imagem abaixo:

mvc-shceme-feat.png

As linhas contínuas definem uma comunicação direta, enquanto as linhas pontilhadas/traçadas definem uma ligação indireta. Em POO, é fácil pensar como trabalhar e criar essas conexões. Já proceduralmente falando, é um pouco complexo manter a separação. No final das contas, o custo de desenvolvimento para realizar essa interação, de forma procedural, é tão elevado que não vale o benefício.

 

MIGRAÇÃO: Caso eu seja obrigado a refazer meu projeto orientado a objeto, o que eu preciso saber que irei encarar pela frente? É algo que leva tempo, mas existe alguma forma de tornar essa migração facilitada?

É a quebra de paradigma. Quando começa a se estudar POO, é muito difícil "pensar" em POO. É do nosso consciente pesar em programação top-to-down, execução linha-à-linha. Na orientação à objetos, apesar de seguir uma linearidade, o pensamento não é mais o mesmo.

 

Acho que a maior "epifania" que ocorre é com os princípios S.O.L.I.D., pois, são essências para qualquer desenvolvedor POO.

 

PDO / MySQLi: PDO é um método montado em cima do paradigma orientado a objeto, sendo assim posso dizer que PDO é orientado a objeto? Minhas manipulações sql/php com pdo são orientadas a objetos apenas por utilizá-lo? O mesmo para MySQLi.

As SQLs continuarão sendo SQLs e são estruturadas (Structured Query Language), o fato de usar PDO/MySQLi não mudará a essência da linguagem. A manipulação, em PHP, é POO, mas pode ocorrer em um script procedural

 

MySQLi permite ser totalmente procedural.

 

OBS: Boatos de que BOA PARTE da documentação do PHP é estrutural, isto é por si verdade ou não, tudo que existe em PHP estruturado/procedural também existe em PHP orientado a objeto?

A documentação era toda procedural, pois era assim que a linguagem era. Mas a linguagem foi evoluindo e, certas funções, foram agrupadas em bibliotecas. Agora, num passado recente, algumas bibliotecas foram criadas sem a existência de um código procedural preexistente. Mas é muito raro encontrar algo, no PHP, em POO que não possa ser feito de forma procedural.

 

Eu consigo argumentar para uma banca examinadora de TFC que meu projeto não foi desenvolvido orientado a objeto por algum bom motivo (igual este da documentação se for verdade)?

 

Eu realizei testes de software (funcional/unitário com badboy e análise estática com rips) incrivelmente consegui zerar as falhas de sql injection, session e banco e quase zerar os erros de cross-scripting. Não consegui resolver file manipulation e alguns cross-scripting que quando apliquei a correção com htmlentities deu alguns bug na página.

 

Enfim, com os testes de software consigo "provar", ou melhor, argumentar que minha gambiarra é funcional !!! Porém agora estou preso no MVC/Orientação a Objeto.

 

O que vocês podem me ajudar nesse conceito galera? Estou fudido e tenho que desenvolver orientado a objeto ou existe uma saída? rsrs

Qual o motivo dessa argumentação? Estou querendo entender o seu ponto para explicar que todo o sistema deve ser procedural.

 

Outro ponto a ressaltar, é o benefício entre programadores POO e procedural, que é nenhum. Mas não ter benefício, não significa que as coisas serão feitas de forma similares.

Compartilhar este post


Link para o post
Compartilhar em outros sites

@Gabriel Heming

Excelentes explicações amigo, bem objetivo e detalhado!

 

 

 

Qual o motivo dessa argumentação? Estou querendo entender o seu ponto para explicar que todo o sistema deve ser procedural.

Outro ponto a ressaltar, é o benefício entre programadores POO e procedural, que é nenhum. Mas não ter benefício, não significa que as coisas serão feitas de forma similares.

 

É o seguinte, eu sou acadêmico de Engenharia de Software e eles cobram o máximo para que o projeto/sistema seja algo bem organizado e principalmente bem definido, isto significa que, o que eu escrever na documentação, tem que fazer 100% sentido com a minha aplicação.

 

Eu fiz um esquema de busca que pesquisava 1 campo por vez, em um select, porém o meu banco era tabelas N:N isto torna uma "inconsistência", pois se meu banco é N:N, minha aplicação deveria permitir a busca de 1 ou mais dados relacionados a este campo. Exemplo: Pesquisa de 1 arquivo. Eu devo levar em conta que minha documentação permite que o usuário pesquise no filtro de busca o nome do arquivo, 1, 2 ou mais editoras, 1, 2 ou mais autores, disciplinas, enfim... Este é um "diferencial" do projeto, onde a maioria não possui este recurso, permite apenas a busca de 1 informação por vez.

 

O que vem ao caso:

Eu tenho que estar preparado para caso seja questionado coisas do gênero:

 

- "Onde está a orientação a objeto em seu sistema?". "Porque optou pela forma procedural?"

- "Onde está o padrão MVC citado no DERS?".

 

A Qualidade de Software e garantia da qualidade em software muitas vezes cobram tipagens das quais geralmente se encontra... Ou melhor dizendo, são mais popularizadas com utilização da orientação a objeto.

 

Porém, se eu conseguir levantar argumentos, teorias e citações das quais defendem a utilização do PHP procedural, eu terei uma base relevante para justificar o porque da utilização procedural e em meu ponto de vista e realidade, eu achei mais documentações e mais facilidade em desenvolvê-lo assim do que orientado a objeto. Mas a palavra "facilidade" não é uma justificativa para tal decisão.

 

La no semestre passado, antes mesmo de projetar qualquer coisa via código, na própria documentação, escrevi que o projeto teria MVC. E assim será, porém fiquei confuso se o MVC é bem visto com código procedural e também como ele deveria ser dividido? Pois o que vi sobre MVC foi praticamente apenas relacionado com Java e seus beans, DAO, get/setters, db package, etc.

 

Como ficaria o MVC no PHP Procedural? Você teria algum exemplo mais "prático", para eu ter noção de como funciona na prática.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Como ficaria o MVC no PHP Procedural? Você teria algum exemplo mais "prático", para eu ter noção de como funciona na prática.

 

MVC é um tipo de organização estrutural de sistemas, também chamado de "programação em 3 camadas". Ele provém de Model, View e Controller.

O que isso significa? Significa que um sistema em estrutura MVC possui uma separação de suas partes.

 

Na prática é o seguinte: Antes do padrão MVC, se colocava tudo junto, em uma mesma página php, por exemplo, o HTML, o PHP, o CSS, o JavaScript e etc.

 

Com o padrão MVC temos a separação das coisas, sendo assim, teremos: Uma página HTML, que é a View, uma página PHP sendo o Controller, e uma página PHP sendo o Model. Fora isso, também, hoje, é padrão termos o CSS e o JS em arquivos externos, apenas sendo referenciados na View.

 

O View, é a visualização, ou seja, o que é exibido ao usuário. Ele é basicamente HTML, CSS e JS. Pode ser escrito em HTML mesmo, ou em PHP, tanto faz, desde que seja um arquivo que só tenha essa função.

 

O Controller é o responsável por toda a regra de negócio. É ele que vai dizer o que deve ser feito, como deve ser feito e quando vai ser feito.

 

O Model é o modelo da coisa. É ele quem determina quais atributos o objeto terá, e também faz a interação com o Banco de Dados. E SÓ ele interage com o BD.

 

EU, PARTICULARMENTE, utilizo um padrão MVCD, digamos assim, pois programo utilizando uma quarta camada. Eu separo o Model, utilizando o mesmo APENAS para o objeto, com seus atributos e funções específicas dele, como uma formatação de exibição e coisas do tipo. A camada de abstração de dados, eu faço na "camada D", chamando-a de Data Object. Assim, ao MEU ver, fica ainda mais separado e organizado, tendo cada coisa em seu lugar.

 

Orientação a Objeto é um tipo de programação, que também pode ser utilizado sem o padrão MVC. Sendo assim, são duas coisas distintas.

É possível fazer um sistema no padrão MVC, sem OO? Sim, é possível. É viável? Não, não é. É fácil? Também não.

E por que não é viável?

 

Imagine um sistema de Pedidos, por exemplo. Você terá um cadastro de clientes, um de produtos e outro dos pedidos em si. Se você não tratar cada "cadastro" como um objeto separado, na parte de pedidos, você terá que repetir quase todo o código dos clientes e dos produtos, para poder criar o pedido, tornando assim o desenvolvimento muito mais trabalhoso.

 

Imagine que neste mesmo sistema, você tenha que exibir o pedido em umas 3 partes e de 3 formas diferentes. Você terá que programar em cada exibição a consulta dos dados, o tratamento e a exibição dos mesmos. Ou seja, se você tiver que alterar, adicionar ou remover algum atributo do pedido, terá que fazer isso pelo menos 3 vezes, pois, não sendo um objeto, você fez com que em cada página ele fosse algo independente. MESMO sendo no padrão MVC.

 

Posto isso, a MINHA opinião é que, hoje, sendo MVC ou não, a boa prática e o bom senso nos "obrigam" a fazer tudo em OO, sendo MVC ou não.

 

Eu, pessoalmente, não consigo nem mais olhar para códigos fontes que não estejam no padrão MVC, sério, me causa arrepios quando vejo HTML no meio de PHP, e coisas do tipo.

 

Da mesma maneira, não consigo fazer mais nada hoje que não seja em OO, devido à facilidade, rapidez, consistência, qualidade e agilidade no suporte e alterações deste tipo de programação.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Dserma, uma pequena correção:

 

 

 

O Controller é o responsável por toda a regra de negócio. É ele que vai dizer o que deve ser feito, como deve ser feito e quando vai ser feito.

 

A camada responsável pela tua regra de negócio é a model. O controller, como o próprio nome sugere, é o cérebro do sistema, ou seja, lidam com as requisições web, dados de formulário etc..

Compartilhar este post


Link para o post
Compartilhar em outros sites

Dserma, uma pequena correção:

 

 

 

O Controller é o responsável por toda a regra de negócio. É ele que vai dizer o que deve ser feito, como deve ser feito e quando vai ser feito.

 

A camada responsável pela tua regra de negócio é a model. O controller, como o próprio nome sugere, é o cérebro do sistema, ou seja, lidam com as requisições web, dados de formulário etc..

Compartilhar este post


Link para o post
Compartilhar em outros sites

Dserma, uma pequena correção:

 

 

A camada responsável pela tua regra de negócio é a model. O controller, como o próprio nome sugere, é o cérebro do sistema, ou seja, lidam com as requisições web, dados de formulário etc..

 

Augusto, creio que me expressei mal quanto à "regra de negócio". Como você pode ver, após isso eu disse que o controller é o responsável por dizer o que, quando e como esse o que será realizado. Na minha lógica de explanação ao colega, chamei isso de "regra de negócio", pois, o controller é quem dita as regras de, novamente, o que, quando e como esse o que será realizado.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Pessoal...

 

Não tem jeito, não vou poder correr do MVC / Orientação a Objetos.

 

Agradeço a todos pelas explicações bem detalhadas, muito obrigado. Retornei aqui para tirar uma última dúvida sobre o assunto...

 

Terei que "migrar" meu projeto que está pronto em PHP estruturado para PHP orientado a objetos. É preciso utilizar algum framework tipo cakePHP / codeIgniter? Para algum benefício relacionado a MVC ou alguma outra coisa?

 

Posso meter a cara no código puro mesmo? O que me recomendam?

Estou bem chateado... Tenho nem 1 mês para tentar passar meu projeto para orientado a objeto com mvc... Missão meio impossível, mas vamos lá, é fazer ou fazer...

Compartilhar este post


Link para o post
Compartilhar em outros sites

OBS: A não ser que eu consiga JUSTIFICAR o porque não utilizei MVC no projeto. Alguém de vocês tem argumentos para esta justificativa? hehe

 

Pesquisando na internet, nada "concreto", quando falo justificar, digo... Baseado em documentação, artigo, algo publicado, o que não vale... Um blog/fórum, site que não tenha sido publicado cientificamente.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Framerwork é uma ferramenta, normalmente em MVC. Não necessariamente necessita de um, mas facilita muito. Para entender melhor, deve pensar em trabalhos reais.

 

É mais fácil realizar uma conta complexa com uma calculadora ou sem?

Para esse cálculo, é melhor uma calculadora comum ou científica?

Ter uma HP 12c (calculadora financeira) me trará algum benefício perante as demais?

 

Quanto a justificativa, é prós e contras. Todas as arquiteturas tem seus prós e contras. Não é porque ela é muito utilizada que seja a melhor. Talvez ela apenas seja a melhor "pensada" no momento para alguma determinada ação. As vezes, a justificava é apenas porque é a mais rápida a ser implementada e/ou é a única que o desenvolvedor sabe utilizar. Mas com certeza o MVC, atualmente, é mais utilizado pois a grande maioria de frameworks que o utiliza.

 

Suas justificativas, no meio acadêmico, devem vir de bibliografia. Você não conseguirá justificar, através de livros, que criou um sistema MVC de forma procedural. Isso porque, na literatura, é tudo orientado à objetos. Principalmente quando os "mestres em arquitetura" (das antigas e que não programavam nada nas linguagens atuais) exemplificavam MVC com OO.

 

Agora, quanto a justificar o fato de não utilizar uma arquitetura, é fácil, pois a arquitetura é utilizada para resolver um problema (e acaba criando outros). Dessa forma, é bom entender a necessidade do seu sistema, quais os pontos que quer abordar nele e, então, escolher a arquitetura que melhor de adequa a ele.

 

No meu TCC de pós, houve colegas que justificaram, a arquietura/linguagem escolhida, como questões de aprendizagem e dizer que é possível fazer daquela forma. Você pode enumerar os pontos cruciais de uma arquitetura e expor que é possível realizar de outra forma. Mas isso depende da linha do seu curso, se é sobre questões práticas e implementação ou sobre linhas de pesquisa. Lembrando que, na linha de pesquisa, pesa muito o conhecimento que isso ira agregar para as futuras gerações de programadores.

 

Sobre arquiteturas atuais, com as questões web, eu acredito que a RESTful esteja entrando como a bola da vez. Pois divide as responsabilidades e diminui o tráfego de dados entre cliente x servidor.

 

Seria o ciclo de reinvenção da computação, aonde no início tínhamos os mainframes processando e os terminais burros somente para acesso. Depois, removeu-se os mainframes e o processamento dividiu-se entre os PCs.

 

Agora, tínhamos o cloud (como se fossem mainframes) para centralizar toda a informação e o browser (como se fossem terminais burros) para acesso. E , com o avanço do javascript, estamos novamente dividindo o processamento e diminuindo o I/O entre servidor x terminal.

Compartilhar este post


Link para o post
Compartilhar em outros sites

Como vai.

 

Se for para agilizar algo, pode usar algum framework, no entanto, você vai precisar escrever e estudar as coisas.

 

Conheço alguns ai que se diz desenvolvedor, mas quando você olha o trabalho do cara, nota-se que é alguém muito bom em coisas prontas e não em programação.

 

Se você dirigir sua mente para a programação, em breve vai dominar facilmente qualquer framework ou novas linguagens, não adianta tentar correr sem aprender andar primeiro.

 

Ontem eu estava dando uma olhada na linguagem swift da Apple, estudei um pouco do manual disponibilizado gratuitamente pela própria empresa, fiquei cerca de uma hora e neste momento aqui agora, posso abrir meu notepad++ e escrever alguma coisa utilizando esta linguagem e isso só é possível porque antes estudei programação do zero by hand.

 

Trabalho nesta área faz uns sete anos, imagine se fossem sete anos de WordPress ou CakePHP, neste momento eu seria praticamente um copiador e não conseguiria criar nada quanto mais, por exemplo aprender outras linguagens.

Compartilhar este post


Link para o post
Compartilhar em outros sites

 

Seguindo a risca o que diz o MVC, e considerando a teoria, é possível. O MVC define uma estruturação em três camadas, com o foco principal na view. Como as camadas são estruturadas, fica conforme o custo x benefício.

 

Se for pensar em questões históricas, o MVC teve sua composição através das classes do Smaltalk. Mas, apenas utilizar classes, não significa ser POO.

 

Veja bem, conforme a imagem abaixo:

mvc-shceme-feat.png

As linhas contínuas definem uma comunicação direta, enquanto as linhas pontilhadas/traçadas definem uma ligação indireta. Em POO, é fácil pensar como trabalhar e criar essas conexões. Já proceduralmente falando, é um pouco complexo manter a separação. No final das contas, o custo de desenvolvimento para realizar essa interação, de forma procedural, é tão elevado que não vale o benefício.

Gabriel....o que inicia a aplicação? um controller ou uma view? o autoload da aplicação é um controller ou model?

Compartilhar este post


Link para o post
Compartilhar em outros sites

Literalmente falando, é o controlle. Mais precisamente o Front Controller, o qual não é um Controller dentro do padrão MVC.

 

Aplicações mais antigas realizavam o request diretamente para o controller (o C do MVC), nesse caso, o controller era responsável por carregar o que fosse necessário para o seu uso (algo que está de acordo com a necessidade).

Compartilhar este post


Link para o post
Compartilhar em outros sites

Não, são associações indiretas. Mais precisamente é o conhecimento que cada componente tem de outro.

 

Não é de responsabilidade do MVC definir como você deve implementar a sua aplicação (require/include é um exemplo).

 

Acho que a melhor explicação que você pode encontrar está nestes posts:

http://forum.imasters.com.br/topic/458278-como-pensar-em-orientacao-a-objetos/?p=1816034

http://forum.imasters.com.br/topic/425372-padrao-active-record/?p=1685860

 

 

Resumindo:

 

é importante saber que o foco do MVC é a View, tudo no MVC (ao menos em teoria) foi concebido para facilitar a implementação da View.

 

As setas/linhas contínuas, são associações diretas.

 

O Controller acessa ambos Model e View, tem conhecimento sobre como buscar dados na model e como devem ser enviados para a view.

 

A View acessa a Model. Apesar de não acessar o objeto Model, ela acessa os dados que, por sua vez, são de total responsabilidade da Model. Além disso, tem total conhecimento sobre como são os dados/objetos (responsabilidade da model), como devem ser acessados para serem renderizados e, em alguns momentos, tem total conhecimento que uma solicitação/interação, com algum componente, resultará em um acesso com a Model.

 

Já as setas/linhas pontilhadas, são associações indiretas.

 

Basicamente, a View não tem conhecimento que o impacto de uma de suas ações pode se conectar com um Controller. A View sabe que, ao clicar naquele botão do formulário e, ao realizar o submit, irá implicar em uma nova requisição. Entretanto, não tem conhecimento que essa requisição será respondida por um Controller. Apenas sabe que há uma nova requisição.

 

Já a Model, não tem conhecimento algum sobre a View (assim como View não conhece o Controller). Mas, em determinadas situações, uma alteração na Model deve ser propagada para as demais camadas (isso inclui a View) sem o conhecimento da Model.

 

Como por exemplo, um dado é alterado no SGBD e essa alteração deve ser propagada para as demais camadas. A Model não sabe que existe uma camada além dela, mas existe algum componente, responsável por esse conhecimento, seja um Observer, Mediator ou qualquer componente. E, diferente de alguns componentes acessados pela View, a Model não tem o conhecimento sobre as reações de sua ação.

Compartilhar este post


Link para o post
Compartilhar em outros sites

  • Conteúdo Similar

    • Por First
      Olá a todos!
       
      Eu estou criando um sistema do zero mas estou encontnrando algumas dificuldades e não estou sabendo resolver, então vim recorrer ajuda de vocês.
      Aqui está todo o meu código: https://github.com/PauloJagata/aprendizado/
       
      Eu fiz um sistema de rotas mas só mostra o conteúdo da '/' não sei porque, quando eu tento acessar o register nada muda.
      E eu também quero que se não estiver liberado na rota mostra o erro de 404, mas quando eu tento acessar um link inválido, nada acontece.
      Alguém pode me ajudar com isso? E se tiver algumas sugestão para melhoria do código também estou aceitando.
       
       
      Desde já, obrigado.
    • Por janir.matheus
      Bom dia,
       
      Preciso de ajuda ajuda para resolver o problema de SIGSEGV, basicamente tennho um zconection dentro de uma classe e recebo erro quando tento acessá-lo. Segue um trecho da classe:
      unit unt_classconexao; {$mode objfpc}{$H+} interface uses Classes, SysUtils, ZConnection, ZDataset; type { tConexao } tConexao = class private public vConector : TZConnection; function Listar_Usuarios:TZReadOnlyQuery; procedure Conectar_Banco; end; implementation { tConexao } function tConexao.Listar_Usuarios: TZReadOnlyQuery; var zrquery : TZReadOnlyQuery; begin Conectar_Banco; try zrquery := TZReadOnlyQuery.Create(nil); zrquery.Connection := vConector; zrquery.SQL.Clear; zrquery.SQL.Text := 'SELECT * from tbl_profissionais'; zrquery.Open; Listar_Usuarios := zrquery; finally end; end; procedure tConexao.Conectar_Banco; begin //vConector := TZConnection.Create(nil); vConector.HostName := 'localhost'; vConector.Port := 3306; vConector.Database := 'Caps'; vConector.Protocol := 'mysql-5'; vConector.User := 'root'; vConector.Password := ''; vConector.Connected := true; end; end. Após isso tento fazer uso dessa classe para popular um DBGrid:
      unit unt_frmprincipal; {$mode objfpc}{$H+} interface uses Classes, SysUtils, DB, Forms, Controls, Graphics, Dialogs, Menus, DBGrids, ZConnection, unt_classconexao; type { Tfrm_principal } Tfrm_principal = class(TForm) DataSource1: TDataSource; DBGrid1: TDBGrid; MainMenu_frmPrincipal: TMainMenu; MenuItem_AplicativoSair: TMenuItem; N1: TMenuItem; MenuItem_AplicativoLogin: TMenuItem; MenuItem_Aplicativo: TMenuItem; procedure MenuItem_AplicativoLoginClick(Sender: TObject); private public vConexao : tConexao; end; var frm_principal: Tfrm_principal; implementation {$R *.lfm} { Tfrm_principal } procedure Tfrm_principal.MenuItem_AplicativoLoginClick(Sender: TObject); begin //vConexao := tConexao.Create; DataSource1.DataSet := vConexao.Listar_Usuarios; end; end. A mensagem de erro que recebo dá a entender que o problema ocorre logo que o zconnection começa a ser configurado, como vocês podem ver pelos trechos comentados eu tentei instanciar o componente também sem sucesso. Não tenho experiencia com POO e tenho certeza que estou cometendo um erro bobo, então peço uma explicação sobre como resolver isso. Agradeço de antemão a quem puder me ajudar.
       
      PS. Estou usando o Lazarus.
    • Por sergiosfpereira
      Boa tarde a todos,
       
      Estou estudando MVC e me deparei com a seguinte situação:

      Tenho uma View que precisa receber dados de dois Models diferentes, então no controller desta View eu tenho a função abaixo:
      public function teste($id) { $this->view->a = $this->getOneA($id); $this->loadModel('b'); $this->view->b = $this->model->getOneB($id); $this->view->render('app/teste'); } O cenário acima me retorna o esperado, pega os dados de A e de B e os deixa disponiveis para a View.
       
      Está correto utilizar esse método ?
       
      Se sim, eu deveria carregar o Model "b" no __construct do controller "a"  ou diretamente na função do controller "a" como neste exemplo?
       
      Se não, qual a melhor maneira de obter dados de diferentes Models?
       
      OBS: todos os controllers são filhos do controller principal e todos os models são filhos do model principal.
       
      E me perdoem se eu estiver falando bobagem, como disse, estou aprendendo e a finalidade aqui é didatica e agradeço a quem puder contribuir.
    • Por unset
      Olá, uma dúvida tenho uma classe que faz upload de imagens e cadastra no banco, como eu faço para executar uma outra classe ação função etc somente apos verificar que todo o upload dos arquivos foi realizado com sucesso?
    • Por lucascientista
      Boa noite, galera é o seguinte eu estou montando um script que pesquisa no banco de dados e mostrar os resultados em uma página php, bem aí que está o problema eu pesquisei alguns sistemas de paginação e de pesquisa e acabei montando meu script, no meu script a pesquisa aparece na primeira página mas quando passo para a página adiante não me é mostrado resultado nenhum já verifiquei tudo e não consigo encontrar o erro, será que alguém pode me ajudar?
       
      <?php #Incluindo a conexão no banco de dados require_once '../dao/conexao/Conexao.php'; $conexao = Conexao::getInstance(); /***********************************************/ #Aqui começa a parte a paginação e pesquisa /**********************************************/ #Limitando o número máximo de resultados que serão mostrados na tela $maximo = 1; #Armazenando o valor da página atual $pagina = isset($_GET["pagina"])? ($_GET["pagina"]): '1'; #Subtraindo 1, porque os registro começam do zero como em um array $inicio = $pagina - 1; #Multiplicamos a quantidade de registros da pagina pelo valor da pagina atual $inicio = $maximo * $inicio; #Agora chega a parte em que fazemos o SELECT para contar os resultados $sql = "SELECT * FROM centroautomotivo"; $stmt = $conexao->prepare($sql); $stmt->execute(); $contagem = $stmt->fetchAll(PDO::FETCH_ASSOC); $total = 0; if(count($contagem)){ foreach ($contagem as $linhas) { #Armazenando o total de registros da tabela para fazer a paginação $total = count($contagem); } } /******************************************************************* * Aqui vai começar a parte da pesquisa, tornando o script em um só ********************************************************************/ #Recebe o termo da pesquisa se existir $termo = (isset($_GET["termo"])) ? ($_GET["termo"]) : ''; #Executa uma pesquisa com o termo pesquisado como parametro - Este SELECT irá servir também para a paginação if(empty($termo)){ //Nada aqui } else{ $sql = "SELECT * FROM centroautomotivo WHERE nomefantasia LIKE :nomefantasia or email LIKE :email ORDER BY idCentro LIMIT $inicio,$maximo"; $stm = $conexao->prepare($sql); $stm->bindValue(':nomefantasia', '%'.$termo.'%'); $stm->bindValue(':email', '%'.$termo.'%'); $stm->execute(); $autocenters = $stm->fetchAll(PDO::FETCH_ASSOC); } <?php require_once '../includes/header.php'; require_once '../controller/paginacaoPesquisaCentro.php'; ?> <div class="container mb-5"> <h1 class="text text-center">Centros Automotivos</h1> <p class="text text-center">Encontre o centro automotivo que mais se encaixa com você</p> <!--Formulário de pesquisa com paginação--> <form method="GET" action=""> <div class="d-flex flex-column bd-highlight mb-3"> <div class="p-2 bd-highlight"><img src="../img/Logotipo.png" class=" img-fluid rounded mx-auto d-block"></div> <div class="p-2 bd-highlight d-flex justify-content-center" style="margin-top: -10px;"><input type="text" name="termo" class="form-control" style=" width: 60%;" placeholder="Pesquise pelo Centro Automotivo!"/></div> <div class="p-2 bd-highlight d-flex justify-content-center"><button type="submit" class="btn btn-outline-primary"><i class="fas fa-search"></i>&nbsp;Pesquisar</button></div> </div> </form> <!--Fim do formuláio de pesquisa--> <!--Início dos resultados da pesquisa--> <?php if(!empty($autocenters)){?> <?php foreach ($autocenters as $autocenter) { ?> <center> <div class="card mb-3" style="max-width: 540px;"> <div class="row no-gutters"> <div class="col-md-4"> <img src="../controller<?php empty($autocenter["foto"])? 'images/pic.png' : $autocenter["foto"] ?>" class="card-img img-fluid" width="150px" height="150px"> </div> <div class="col-md-8"> <div class="card-body"> <p class="card-text text-justify"><?php $autocenter["nomefantasia"]?></p> <p class="card-text text-justify"><small class="text-muted"><?=$autocenter["email"]?></small></p> </div> </div> </div> </div> </center> <?php }//Fechamento do foreach?> <div id="alignpaginacao"> <?php //determina de quantos em quantos links serão adicionados e removidos $max_links = 6; //dados para os botões $previous = $pagina - 1; $next = $pagina + 1; //usa uma funcção "ceil" para arrendondar o numero pra cima, ex 1,01 será 2 $pgs = ceil($total / $maximo); //se a tabela não for vazia, adiciona os botões if($pgs > 1 ){ echo "<br/>"; //botao anterior if($previous > 0){ echo "<div id='botaoanterior'><a href=".$_SERVER['PHP_SELF']."?termo={$termo}?pagina=$previous><input type='submit' name='bt-enviar' id='bt-enviar' value='Anterior' class='button' /></a></div>"; } else{ echo "<div id='botaoanteriorDis'><a href=".$_SERVER['PHP_SELF']."?pagina=$previous><input type='submit' name='bt-enviar' id='bt-enviar' value='Anterior' class='button' disabled='disabled'/></a></div>"; } echo "<div id='numpaginacao'>"; for($i=$pagina-$max_links; $i <= $pgs-1; $i++) { if ($i <= 0){ //enquanto for negativo, não faz nada }else{ //senão adiciona os links para outra pagina if($i != $pagina){ if($i == $pgs){ //se for o final da pagina, coloca tres pontinhos echo "<a href=".$_SERVER['PHP_SELF']."?pagina=".($i).">$i</a> ..."; }else{ echo "<a href=".$_SERVER['PHP_SELF']."?pagina=".($i).">$i</a>"; } } else{ if($i == $pgs){ //se for o final da pagina, coloca tres pontinhos echo "<span class='current'> ".$i."</span> ..."; }else{ echo "<span class='current'> ".$i."</span>"; } } } } echo "</div>"; //botao proximo if($next <= $pgs){ echo " <div id='botaoprox'><a href=".$_SERVER['PHP_SELF']."?termo={$termo}?pagina=$next><input type='submit' name='bt-enviar' id='bt-enviar' value='Proxima' class='button'/></a></div>"; }else{ echo " <div id='botaoproxDis'><a href=".$_SERVER['PHP_SELF']."?pagina=$next><input type='submit' name='bt-enviar' id='bt-enviar' value='Proxima' class='button' disabled='disabled'/></a></div>"; } } ?> </div> <?php }//Fechamento do if?> <!--Fim dos resultados da pesquisa--> <!--Início da paginação--> <!--Fim da paginação--> </div> <?php require_once '../includes/footer.php'; ?>  
      Bem aí está meu código, fico muito agradecido se puderem me ajudar.
×

Informação importante

Ao usar o fórum, você concorda com nossos Termos e condições.