On 12/19/06, Rodrigo Dias Arruda Senra <[EMAIL PROTECTED]> wrote:
>  Recomendo a leitura de "Python Web Framework Templating Systems
> Compared and Contrasted" [1].

Grande dica, Senra! Vou ler.

>  Mas fora isso, toda vez que um .zpt fica cabeludo é só varrer a feiúra
>  para um .py e boa.

Concordo 110%. É por isso que eu disse antes que parte da minha
ressaca vem do modo como ZPT é (ab)usado no Plone. Veja este outro
exemplo, extraido do news_portlet.pr:

<a href="#"
   class="tile"
   tal:condition="python:'news' in portal.contentIds()"
   tal:attributes="href string:${utool}/news"
   i18n:translate="box_news">News</a>
<a href="#"
   class="tile"
   tal:condition="python:'news' not in portal.contentIds()"
   tal:attributes="href string:${utool}/news_listing"
   i18n:translate="box_news">News</a>

São 10 linhas de código para gerar um link news ou news_listing. Sim,
esta é a única diferença! É um exagero causado por um estilo de
"resolver tudo no template" que tem reinado no Plone historicamente.

Como eu acho que este trecho deveria ser escrito:

<a href="#"
   class="tile"
   tal:attributes="href view/getNewsPageLink"
   i18n:translate="box_news">News</a>

4 linhas em vez de 10; 112 caracteres em vez de 349.

Mas o que seria "view/getNewsPageLink"? Um método (por hora
imaginário) que teria umas 4 linhas, usaria o velho e bom if/else em
vez do desengonçado tal:condition, teria performance melhor,
simplificaria o ZPT, e seria reutilizável (ao contrário da solução via
tal:, que só pode ser reutilizada na base do copiar-e-colar... sempre
uma péssima idéia).

Por sinal, tem até um design pattern que prega isto: chama-se View
Helper [1]. No Ruby on Rails, por exemplo, toda aplicação tem
diretórios de helpers onde este tipo de código é colocado.

__________
LUZ NO FIM DO TÚNEL

Com a integração do Five, o Plone está indo no caminho certo. No
próprio news_portlet.pt já vemos uma mudança importante do Plone 2.1
para o 2.5. Veja o início do portlet:

<div metal:define-macro="portlet"
     tal:define="view context/@@news_view;
                 results python:view.published_news_items()[:5];
                 news_link view/all_news_link"
     tal:condition="python:test(template.getId()!='news' and results, 1, 0)">

Note o uso do método view.published_news_items, em vez de uma imensa
expressão python invocando o portal_catalog com 5 linhas de
parâmetros, como era feito antes. É um avanço, e a view é o lugar para
os helper methods. Agora é usar mais este estilo nos nossos projetos
tb! Para diminuir a verborragia, seria legal se a view ficasse
acessível implicitamente, por convenção, sem precisar usar a primeira
linha do define.

Aliás, acabei de notar: parece que o outro método da view,
all_news_link faz exatamente aquilo que o nosso getNewsPageLink faria,
mas ele não é usado. Acho que faltou tempo de terminar a refatoração
deste template para o Plone 2.5, mas claramente estamos no caminho
certo!

Agora, falando no código citado, outra coisa feia espalhada pelo
código do Plone é o uso redundante da função test, como no exemplo
acima. Porque fazer "test(booleano, 1, 0)"? E por sinal, será que o
lugar certo para determinar se um portlet deve ou não aparecer é no
ZPT do portlet? Quem já viu um site Plone com uma coluna lateral em
branco deve concordar que não.

Peço a todos os colegas, e muito especialmente os commiters do Plone
que prestigiam esta lista, que entendam estas como críticas
construtivas.

E também como um convite à auto-crítica e aperfeiçoamento pessoal:
afinal, aquele que nunca abusou do ZPT que jogue a primeira pedra!

> Mesmo assim, ainda que imperfeito não vi substituto para
>  o que o Plone "entrega".

Eu também não!

[ ]s
Luciano

[1] http://www.corej2eepatterns.com/Patterns2ndEd/ViewHelper.htm

Responder a