Srs.
Podem apostar que só postei aqui depois de muito pesquisar no google.
Diga-mos que eu tenha a seguinte situação:
HtmlPanelGroup panel = new HtmlPanelGroup();
panel.getChildren().add(new HtmlCommandButton()); // Funciona pq o HtmlCommandButton é um UIComponent
panel.getChildren().add(new AjaxCommandButton()); // Não Funciona pq o AjaxCommandButton não é um UIComponent
Como faço para inserir um AjaxCommandButton(UIComponentTagBase) nos container’s que existem na API do JSF?? Alguém sabe??
Com o passar do tempo trabalhando com JSF, tenho formada, pelo menos por enquanto, as seguintes opiniões:
Procure sempre um componente que faça o que você pretende, caso não encontre, pese muito bem o custo/benefício de se contruir um componente ou mude o seu projeto de interface para se adequar a uma nova realidade;
Interfaces extremamente dinâmicas, mesmo com JSF 2, ainda estão longe de serem uma realidade. O seu caso é um exemplo, muitos “componentes” são implementados através de tags, ou seja, além de (muitas delas) serem processadas muito cedo no ciclo de vida JSF (RESTORE_VIEW) não podem ser adicionadas através de binding. A tag ui:include é um exemplo clássico. Imagine o cenário onde você quer adicionar includes dinâmicos através de Ajax: no seu include você aponta para uma propriedade de um bean de sessão contendo a viewId que você deseja ir e ações setam esse atributo para mudar o viewId de acordo com a necessidade. Parece simples? E é! Mas com JSF 2 simplesmente não dá para fazer, pelo menos não de forma simples. A tag ui:include é executada na fase RESTORE_VIEW, ou seja, vai no bean de sessão e dá um getViewId no seu bean de sessão, depois lá na frente (INVOKE_APPLICATION) é invocada a ação que muda a viewId no bean de sessão, ou seja, nesse momento ao renderizar a página vai ser exibida ainda a viewId anterior e não a setada pela sua ação. Tem workarounds que fazem duas requisições Ajax, mas isso, além de ser um típico caso de POG, gera outros problemas, pq vc passa a ter que aumentar o scopo dos seus beans, tendo em vista que vão ter que manter o estado entre, no mínimo, duas requisições. Fora problemas com viewid duplicados em virtude do render partial e outras coisitas mais.
