Separar o HTML do PHP

[williamespindola]

Remover todo o html / css / javascript que estiver na pasta src. os assets (css/javascript), inicialmente vão pra pasta public. O HTML deve ser extraído para uma pasta chamada templates e renderizado usando o Twig.

Isso iria começar a separar a camada de template do nosso código, assim mudanças de UI não precisam ser feitas no código e nosso código para a ficar mais limpo, para que as próximas mudanças sejam mais fáceis.

[eberfreitas]

Existe um problema com relação a isto hoje... O sistema depende fortemente de um "form builder" que foi desenvolvido, que é extremamente complexo e cheio de camadas e desconsidera qualquer utilização de um sistema de templates.

Este form builder agiliza muita coisa uma vez que você entende como ele funciona (essa parte toma tempo), mas é algo totalmente fora dos padrões e é extremamente confuso.

Acho que antes de qualquer coisa a gente poderia pensar em como melhorar esta parte do sistema ou, no mínimo, levar ela em consideração na hora de extrair o HTML pra um template engine.

Alguém por aí já deu uma olhadinha nesses códigos?

[williamespindola]

@eberfreitas pode me ajudar a entender melhor como isto funciona hoje? Me de um exemplos de onde o form builder é aplicado; E como o php se comunica com o front por favor.

[farribeiro]

Queria saber... Qual será a FHS (PSR-4) do ieducar? Está no planejamento estratégico?

[eberfreitas]

@williamespindola pega este exemplo:

https://github.com/portabilis/i-educar/blob/master/ieducar/intranet/educar_configuracoes_labels.php

As seguintes classes estão envolvidas também:

https://github.com/portabilis/i-educar/blob/master/ieducar/intranet/include/clsBase.inc.php https://github.com/portabilis/i-educar/blob/master/ieducar/intranet/include/clsCadastro.inc.php https://github.com/portabilis/i-educar/blob/master/ieducar/intranet/include/clsCampos.inc.php https://github.com/portabilis/i-educar/blob/master/ieducar/lib/Core/Controller/Page/Abstract.php

Alguns comentários no arquivo vão te ajudar a entender +/- o que tá rolando.

[farribeiro]

Como estão separando a VISÃO do MODELO/CONTROLE, já definiram a nova estrutura de diretórios? Onde ficarão estes HTMLs

Link #275

[farribeiro]

Ao escopo desta ISSUE... unificar os ASSETS

Link #254 e #253

listei todos os Assets:

Reprimido

Alguns deles tem hashs idênticos

[williamespindola]

@eberfreitas dei uma olhada, esta bem complicado, mas não esta impossível. Consegue me explicar se existe e como funcionar hoje algum mecanismo de rota? Exemplo clica aqui e vai chamar este arquivo ou controller. Tem alguns arquivos .tpl isto é algum template? Existe alguma parte que esta isolada? Alguma página que posamos chamar um link ali termos algum formulário ou comportamento isolado? Caso não tenha podemos pegar um formulário/pagina que seja bem simples. Tenho alguma idéias, mas preciso colocar em prática e mostrar para vocês.

[eberfreitas]

Realmente não é impossível, só não é trivial.

Atualmente não existe um router. Algumas áreas do sistema obedecem a regras definidas, por exemplo, no .htaccess (via Apache) mas grande parte é um acesso direto aos arquivos que estão na pasta ieducar, então basta apontar o navegador para o arquivo diretamente e você vai poder vê-lo em ação.

Um bom lugar pra dar uma olhada seria por exemplo o cadastro de país:

/intranet/public_pais_lst.php

Ah! E seria legal você jogar a ideia aqui. A galera tem experiência e vai poder te dizer melhor como melhorar a ideia ou se ela seria algum tipo de perda de tempo. Pra você não desperdiçar teu trabalho acho que era legal propor algo antes de botar a mão na massa, mas fica à vontade :)

[ghost]

não quero ser chato, pq parece que volto a um tema que já foi decidido, mas não seria legal, sem prejudicar o que está no roadmap, ter um php router? o router do symphony é mais elaborado e vai precisar do http foundations (e ter seu proprio sistema de exceções).

então minha abordagem seria, por enquanto, antes do symphony, usar um router mais simples, dessa forma teriamos router. (vi algo como url helper em algum lugar, não sei se ajuda).

em um segundo passo, poderia criar 2 arquivos, bootstrap e middleware, para incluir no router (front-controller), mas falo middleware sem necessidade inicialmente, apenas o bootstrap com os includes que inicializariam o core e permitiria acessar o i-educar. (não me refiro ao já existente includes/bootstrap.php, mas um arquivo que require_once todos os arquivos necessarios para se poder acessar o i-educar, na falta de melhor termo)

dessa forma acho que avançariamos algo.

[incidental] (laravelizando eu procuraria um gerador de models eloquent do database, mas que seria um outro issue)

no caso do laravel o sistema de routing eu acho que é o lumen, e provavelmente será tão elaborado quanto o do symphony. (e descobri semana passada que ele por default serve as páginas fora do rota, que eu não sabia) [/incidental]

então a abordagem seria pegar um http-router desses que tem no github (teria que dar uma olhada qual serviria melhor) e basicamente tudo continuaria a funcionar exatamente igual, com a diferença de poder criar rotas inicialmente, e em um segundo momento de acessar ao core, acho.

ps: esse assunto se refere a 2 tópicos ao mesmo tempo, a API e a separar o html do php, acho, com uma abordagem mais radical, de realmente isolar o back do front.

[ghost]

eu não ia conseguir dormir sem tirar esta duvida.

existe router do laravel na versão standalone, sem querer ser tendencioso, poderia ser usado. qualquer router php generico tbm resolve, é que usar o router do symphony seria mais intrusivo, pelo que li.

só pra lembrar, por baixo do laravel tem symphony, mas tanto o router quanto o doctrine não são "easy tasks" (pelo menos para mim), principalmente se compararmos os seus similares, o eloquent e o router.

[ghost]

em português claro, acho mais facil laravelizar o i-educar do que symphonyzar. :) e me baseio em 2 pontos do roadmap proposto, o router e o orm.

[ghost]

olá @MarceloCajueiro eu não lembro a @ que o sr comentou quando da proposta do roadmap, mas talvez valha a pena ouvir a opinião dele. são 2 pontos específicos e práticos, eu olhei as duas abordagens em relação aos dois tópicos, e para mim (que não sou referência) me pareceu mais tranquilo a abordagem não symphony, e são pontos realmente relevantes para um planejamento do que vai acontecer. (eu não pretendia voltar a este assunto, mas fui impelido pelas circunstâncias)

[ghost]

eu vou tentar explicitar o que eu imagino:

<?php
require_once 'inc/bootstrap.php // inicializa o core,app, kernel ... não sei o termo
require_once 'inc/middleware.php // em um 2 momento faz as validações

Route::ideia('aqui/vai/as/rotas', meuController@crud);

isso estou falando das rotas, por exemplo, não pesquisei muito:

https://github.com/phpgearbox/router

e se quiser aqui tem um roadmap para um momento posterior https://github.com/mattstauffer/Torch eu posso estar engando e ter um versão do router do symphony que não use o http foundations

---

em termos de orm:

link 1: https://jenssegers.com/53/using-eloquent-without-laravel link 2: https://medium.com/@kshitij206/use-eloquent-without-laravel-7e1c73d79977 (que é basicamente a mesma coisa do link 1)

para ter uma referência como seria com o doctrine: link 1: https://busypeoples.github.io/post/slim-doctrine/ (com o slim) link 2: http://doctrine-orm.readthedocs.io/en/latest/reference/configuration.html (documentação oficial)

e por ultimo, um link de forma genérica poderia tentar achar algo assim: https://medium.com/@CristianLLanos/eloquent-models-from-my-database-5d74c632e03c

que teria no doctrine algo assim: https://symfony.com/doc/current/doctrine/reverse_engineering.html

---

Resumindo: Eu acho as 2 abordagens do laravel mais fácil que a do symphony. Sendo principalmente as rotas, já que o doctrine daria para fazer samba tbm, mas aí entra uma coisa minha, já que o doctrine é um ilustre desconhecido para mim.

[ghost]

ps: errei o link do router (mas realmente tem opções a beça no github) : https://github.com/seytar/php-router

aqui tem mais: https://laracasts.com/discuss/channels/laravel/using-routing-outside-of-laravel-without-the-huge-dependency-list

o que eu achei um complicador do router do symphony foi o http foundations, e como vc pode ver o laravel tbm tem essa dependência, só que eu achei routers a la laravel sem essa dependência, e não achei similar para o symphony, pode ser que exista.

[ghost]

a encrenca com syphony, https://tech.yappa.be/symfony-components-in-a-legacy-php-application

mas independente do laravel versus symphony, o que estou chamando atenção é para necessidade de router (front-controller).

então independente de qualquer coisa, se conseguir chegar a uma posição que resolva essa necessidade acho valida (nem que seja de caráter provisório). Eu não consigo colocar o router do symphony no i-educar.

---

desculpe eu ter postado 7x nessa issue, mas era algo que tinha tempo eu queria comentar e não achava oportunidade.

---

ps: 8x para aproveitar a oportunidade

será que não tem 1 router que agrade a rapaziada que a gente já possa ter segunda feira no i-educar?

https://www.google.com/search?q=php+router+github&ie=utf-8&oe=utf-8&client=firefox-b-ab

de tudo que olhei por aí a abordagem de se ter router/api é bem clássica em relação a legacy apps tendo as urls clássicas e as novas convivendo numa boa. então, me parece razoável ser um 1o passo independente (sem prejuízo) de nenhuma outra coisa.

---

vou colocar mais links, apesar de achar que já consegui expor meu ponto de vista: uma pergunta trivial net afora https://www.reddit.com/r/PHP/comments/226cor/whats_a_simple_way_to_do_routing_without/

um exemplo do symphony http://symfony.com/doc/current/introduction/from_flat_php_to_symfony2.html

não tem bicho de 7 cabeças em relação ao assunto. realmente MUITA gente já passou por esta situação e acho que o roadmap já prevê isso, mas enquanto não se materializa, seria handy ter um front-controller (qualquer um)

[farribeiro]

Junte tudo em um único commit

[ghost]

@farribeiro eu estou repetindo o que eu já falei antes, antes de comittar alguma coisa o pessoal precisa dar sinal verde em relação a issue. O plano é symphony router, eu não vou me meter nisso. Existem coisas mais simples que resolveriam o problema, pelo menos por enquanto. Mas não vi ngm tocar no assunto. (Desculpe varios posts, quis aproveitar a oportunidade, vamos ver se vai ter ressonância)

[farribeiro]

Onde se lê commit, entende-se comentário. Ou seja, fazer Squash!

[williamespindola]

@JDias você não entendeu o rumo que a discussão esta tomando e este monte de comentários seus esta apenas sujando a thread. Em nenhum momento alguém falou em adicionar alguma sistema de rotas. E sim se existe algum implementado para entender como o comportamento atual funciona.

[ghost]

@Williamespindola me desculpe o lixo, posso apagar se quiser.

Mas acho que o sr não me entendeu.

Existe sim, planos de utilizar o router do symphony, e não tenho nada contra, estou propondo ter um front-controller mais simples, enquanto o do symphony não se materializa.

[eberfreitas]

A discussão sobre o router é necessária mas acho que ainda não é o momento, muito menos a issue certa :joy: Se vamos ter um trabalho para implementar um router em qualquer momento que seja, acho que vale mais a pena investir tempo numa solução final e não em algo temporário. Já existe uma issue sobre router não? Vamos tentar focar aqui no conteúdo desta issue :+1:

[ghost]

Oi eber, eu não tenho skills para botar o router do symphony.

Mas é que poder fazer rota adianta o lado das apis (com urls restfulls) e essas coisas que o willian falou de um form simples e tals. Eu realmente não sei como o i-educar ainda não tem, é algo bem simples e que fica transversal a tudo. (Desculpe não acompanhar vcs, mas na hora que vc descreveu a situação de pronto eu visualizei a necessidade de um front controller)

[ghost]

Vou respeitar o ritmo de vcs! Mas deixando minha opinião. (Me surpreendi de vc não já ter chegado com um pr de front controller, vc ilustra as situações com maestria)