Não teria como você injetar esse teu bean que recupera as informações no converter e assim ele te entregar os objetos prontos seguindo a lógica específica da tua aplicação?

Para fazer isso, coloque o seam-faces na tua app (2 jars sem configuração nenhuma).

Ops, desculpe os textos repetidos, costumo escrever em bloco de notas antes de postar direto aqui.

Por favor, Gilliard e quem mais for ler a parte que escrevi (“quebra as rotinas CRUD”), não me crucifiquem, rs. Vou retificar o que escrevi. Vejo a grande sacada no uso de converter pois ele está ligado diretamente ao componente. Ou seja, no caso da combobox, não preciso disparar um método via listener/action. O converter já me ajuda nisso. No meu caso eu não precisei utilizar mas quem precisar, é um baita recurso!!

Bom, espero ter entendido bem esse lance de converter.

Abraço,
Rodrigo

Valeu pela resposta. Fiquei em dúvida agora se o uso de converter vai ser interessante para os proximos passos que eu seguir na parte de CRUD usuários, por exemplo.

Explicando melhor minha dúvida, tenho lá a tela de pesquisa onde eu clico em um usuário para editar as informações. Neste caso eu utilizaria no método a recuperação das informações via BO > DAO de forma normal no método, por exemplo, “recuperaUsuario()” sem o uso de converter.

Eu postei lá no blog do Rafael Ponte uma dúvida bem nessa linha de raciocínio onde eu tenho uma situação diferente para o esquema de Estado/Cidade. Tenho lá o meu bean RegiaoBean onde dentro há a lógica para o load de estados e também das cidades de acordo com o estado. Ou seja, este mesmo bean é referenciado nas 2 comboboxs. Neste caso eu questionei ele como utilizaria converter. Nos exemplos que vejo na internet, temos lá um UserBean com atributo “User user” e atributo “List users”. Aí neste caso o converter é tranquilo de se fazer mas para o meu caso que tenho no mesmo managedBean os atributos Estado e Cidade, não consegui visualizar como implementar um converter. Acredito que converter deve ser visto para uma situação bem específica em que realmente eu preciso recuperar as informações para uma determinada ação, e esta situação não deve ser confundida com a recuperação normal do objeto por meio de um método exemplo “buscarUsuario()”. Menciono isso pois no converter lá, chamar direto Dao ou Bo me parece um tanto estranho e além do que “quebra” as rotinas de CRUD que no meu ver devem ser chamadas no managedBean próprio que neste caso seria UsuarioBean.

Abraço,
Rodrigo

Abraço,
Rodrigo

Abraço,
Rodrigo

Parabéns pelo post! Eu estava procurando detalhes sobre este escopo novo do JSF 2 que foi a “salvação da lavoura” para o meu caso que é justamente o citado (Estado/Cidade).

Me parti de rir na parte a seguir:
“Então o JSF pensa: “como esse cara tá submetendo uma cidade sendo que eu nem mostrei os valores desse combo ainda? Essa cara tá me sacaneando, vou tesourar essa requisição dele”.”

Eu postei no blog do Rafael Ponte um texto referente à dúvidas no caso de combos aninhadas e converter. Me bati um monte e no fim não usei converter. Eu utilizo o id e nome como exemplo :

itens.add(new SelectItem(estado.getIdEstado(), estado.getEstado()));

Qual o empecilho de continuar o desenvolvimento da minha aplicação sem utilizar converter ? Qual a real necessidade se, no meu caso, eu só preciso dos ids no retorno ?

Abraço,
Rodrigo

Atualmente estou utilizando o mojarra 2.0.2.FCS com primefaces 2.0.2 e o escopo funciona normalmente. O que pude perceber de problema é com a paginação ajax do componente dataTable do primefaces, que chama o método anotado com @PreDestroy… mas mesmo assim não terde os valores do managed bean.