Filtros: DBFilter, ConvertionFilter, InjectionFilter, ValidationFilter

Mauricio:

O ValidationFilter vai validar diretamente o que vai vir pelo formulário HTML? Porque senão ele ia ter que ficar depois do InjectionFilter. Outra coisa que você deveria levar em consideração é a “transformação” de Strings em outros tipos simples, como Integers, Booleans e essas coisas, uma boa é usar os property editors, como o Spring:

http://java.sun.com/j2se/1.5.0/docs/api/java/beans/PropertyEditor.html

E mais uma coisa, eu to achando esse DbFilter meio “solto” por aí, especialmente porque lá na página do framework você diz que ele não vai fazer tudo. Eu, por exemplo, não usaria esse filtro, porque esse trabalho ficaria pra o meu framework de mapeamento objeto/relacional e eu provavelmente criaria um Filter (da API de servlets) pra fechar as conexões usando ThreadLocal, quando isso fosse necessário. Eu não acho que isso devesse estar aí não, ou pelo menos não como uma coisa “comum” do framework.

Fala Maurício!

Todos os parametros do form html chegam para os filtros e action através do objeto org.mentawai.core.Input, que faz parte do core do framework e é criado automaticamente pelo controller.

Por isso que o ValidationFilter pode ficar antes do InjectionFilter, pois ele vai validar o Input. Depois, se a validação passar, o InjectionFilter pode pegar o Input e injetar na action.

Converters com certeza precisa ter! Penso em fazer bem parecido com a validaçao, ou seja, um filtro de conversão onde vc pode setar um converter para cada campo. O legal do org.mentawai.core.Input é que ele aceita objetos, como um map, logo eu posso pegar uma string que representa uma data e trocar por um Date object por exemplo, usando a mesmo nome do parametro (key).

Então vc terá DateConverter, etc. e poderá também implementar seus próprios converters via a interface Converter, como no caso da interface Rule da validacao.

Eu achei o esquema do Webwork de convertion overkill para algo tão simples:

public class ContactConverter extends ognl.DefaultTypeConverter {
  public Object convertValue(Map ognlContext, Object value, Class toType) {
    if( toType == String.class ) {
      Contact contact = (Contact)value;
      return new String(contact.getContactId());
    } else if( toType == Contact.class ) {
      Integer id = new Integer((String)value);
      Session session = ... // get a Hibernate Session
      Contact contact = (Contact)session.load(Contact.class, id);
      return contact;
    }
    return null;
  }
}

Primeiro ele usa herança e não interface. Depois usa um método com uma assinatura exdrúxula:

public Object convertValue(Map ognlContext, Object value, Class toType);

Pra que esse ognlContext ??? Pra que toType ??? Cada converter deve converter para um tipo só. Pra que criar um converter que pode converter para vários tipos diferentes ???

Acho que assim fica mais clean, simples e qualquer ameba vai entender:

public interface Converter {
    public Object convert(Object value) throws ConversionException;
}

O que vc acha?

Quando ao DBFilter, isso seria uma opção apenas. Em alguns casos que vc precisa de uma Connection para fazer algo, seria legal usar esse filtro, pois ele te garantiria uma connection, tratando de possíveis erros e cuidando de fechá-la na volta. Para persistencia vc pode ignorar isso e usar o Hibernate, sem problemas.

É claro que vc pode fazer o mesmo via filtro de servlet e ThreadLocal, mas pra que se o filtro tem exatamente a mesma funcão. Esse filtro já poderá ser oferecido pelo framework, o que vai reduzir o trabalho do usuário para praticamente zero.

Lembre-se que para o cara que manja, ele não precisa de framework nenhum. Pode fazer um mega-projeto usando servlet/jsp. Mas esse framework não é para as pessoas que manjam, é exatamente para as pessoas que estão iniciando com a coisa e não têm tempo a perder.

É tb para os que manjam mas não querem perder tempo implementando essas coisas.

Eu, pessoalmente, não gostei de como o WebWork faz isso, prefiro usar PropertyEditors, que foram feitos já pensando nisso, além do que, se o cara faz isso usando esse ou aquele framework, como é que ele vai reaproveitar?

Eu acho que o melhor mesmo é fazer como se faz no Spring, ele só usa PropertyEditors, que é uma coisa da própria API do Java, vai estar em praticamente qualquer JVM e ainda vai fazer o código ser simples de ser reutilizado em qualquer outro canto. Além, é claro, de já existirem diversos PropertyEditors prontos pra serem utilizados.

O programador não ia se preocupar com nada, ia simplesmente criar um property editor pra alguma coisa dele e o framework ia se ocupar de fazer o resto do serviço, testando a possibilidade de se transformar ou não o String.

Sobre o DbFilter, sendo apenas uma opção, ele ficaria ótimo, ainda mais se você puder esconder um pool de conexões aí (o DBCP seria uma boa). O usuário não veria, mas a aplicação estaria rodando com o pool, aumentando a velocidade do acesso ao banco de dados.

3 Respostas

Topicos relacionados