Usar visualizações ou não usar visualizações

Question

Parece que agora estou envolvido em um debate com outro programador deste projeto que pensa que as opiniões não têm méritos.Ele propõe um sistema em que o PHP se parece com isto:

$draw = new Draw;
$nav = $draw->wideHeaderBox().
$draw->left().
    $draw->image().
        Image::get($image,60,array('id'=>'header_image')).
    $draw->imageEnd().
$draw->leftEnd().
$draw->left(10).
    '<div id="header_text">'.
        self::defaultSectionText().
    '</div>'.
$draw->leftEnd().

e assim por diante (isso está no controlador, aliás).Agora, seus argumentos para isso realmente fazem algum sentido, ele afirma que, se houver um redesenho, tudo o que precisamos fazer é alterar o HTML em um local e ele mudará automaticamente em todos os lugares.Por alguma razão, porém, esse método ainda me incomoda. Existe algum mérito nas opiniões sobre esse método?Quero dizer, além de não precisar redigitar o HTML manualmente.

Answer 1

Os economizadores de tempo HTML são úteis, mas só são úteis quando são intuitivos e fáceis de entender.Ter que instanciar um new Draw simplesmente não parece muito natural.Além disso, wideHeaderBox e left só terá significado para alguém que conhece intimamente o sistema.E se houver é um redesenho, como as musas de seus colegas de trabalho?E se o wideHeaderBox fica muito estreito?Você alterará a marcação (e estilos, presumivelmente) gerada pelo método PHP, mas deixará um nome de método muito impreciso para chamar o código?

Se vocês apenas ter para usar a geração de HTML, você deve usá-lo intercalado nos arquivos de visualização e onde for realmente necessário/útil, como algo assim:

HTML::link("Wikipedia", "http://en.wikipedia.org");
HTML::bulleted_list(array(
    HTML::list_item("Dogs"),
    HTML::list_item("Cats"),
    HTML::list_item("Armadillos")
));

No exemplo acima, os nomes dos métodos realmente fazem sentido para pessoas que não estão familiarizadas com o seu sistema.Eles também farão mais sentido para vocês quando voltarem a um arquivo raramente visitado e se perguntarem o que diabos estavam fazendo.

Answer 2

O argumento que ele usa é o argumento que você precisa ter Visualizações.Ambos resultam em apenas alterá-lo em um só lugar.No entanto, na versão dele, você está misturando marcação de visualização com código comercial.

Eu sugeriria usar mais um design de modelo.Faça toda a sua lógica de negócio no PHP, configure todas as variáveis ​​que sua página precisa.Em seguida, basta fazer com que a marcação da sua página faça referência a essas variáveis ​​​​(e não lide com nenhuma lógica de negócios).

Você já olhou para o espertinho? http://smarty.php.net

Answer 3

Já fiz algo assim no passado e foi uma perda de tempo.Por exemplo, você basicamente tem que escrever wrappers para tudo o que já pode com HTML e IRÁ esquecer algumas coisas.Quando precisar mudar alguma coisa no layout você vai pensar "Puxa, esqueci disso..agora preciso codificar outro método ou adicionar outro parâmetro".

No final das contas, você terá uma enorme coleção de funções/classes que geram HTML que ninguém saberá ou lembrará como usar daqui a alguns meses.Novos desenvolvedores irão amaldiçoar você por usar este sistema, pois terão que aprendê-lo antes de mudar qualquer coisa.Em contraste, provavelmente mais pessoas conhecem HTML do que suas aulas de desenho HTML abstrato... e às vezes você só precisa sujar as mãos com HTML puro!

Answer 4

Para ser honesto, parece bastante detalhado e difícil de seguir, e parte do código parece conter muitas informações de layout.

Sempre tentamos separar a lógica da saída tanto quanto possível.No entanto, muitas vezes acontece que a visão e os dados estão intimamente ligados, com ambas as partes ditando como a outra deveria ser (por exemplo, em um simples site de comércio eletrônico, você pode decidir que deseja começar a mostrar os níveis de estoque ao lado de cada produto , o que obviamente envolveria alterar a visualização para adicionar o html apropriado para isso e a lógica de negócios para descobrir um valor para o estoque).

Se a ideia de manter 2 arquivos para fazer isso for demais para lidar, tente dividir as coisas em uma parte "Gather data" e uma parte "Display View", obtendo a maioria dos benefícios sem aumentar o número de arquivos que você precisa gerenciar .

Answer 5

Sempre achei muito mais fácil trabalhar diretamente com HTML.Há uma camada de abstração a menos (html -> página da web real/função php -> html -> página da web real) para lidar, então você apenas trabalha em HTML.

Eu realmente acho que a coisa de 'só preciso mudar em um só lugar' não funcionará neste caso.Isso ocorre porque eles ocorrerão muitas vezes quando você quiser alterar a saída de uma função, mas apenas em um lugar.Claro que você pode usar argumentos, mas logo acabará com algumas funções com uma dúzia de argumentos.Que nojo.

Tenha em mente que linguagens/sistemas de modelagem geralmente permitem incluir submodelos, permitindo que você tenha alguns blocos reutilizáveis ​​de HTML.

O resultado final é que se eu tivesse acabado de começar na sua empresa e visse códigos como esse em todos os lugares, meu primeiro pensamento seria: 'Droga!Preciso de um novo emprego novamente.