Trabalhando com xhtml

Quando você preenche o datatable você deve estar preenchendo eles com o próprio objeto, então você cria um método no seu backbean e passa o objeto inteiro selecionado.

pelo q vi backbean é a mesma coisa q ManagedBean http://www.guj.com.br/java/197877-diferen-entre-backing-bean-e-managedbean mas se eu tivesse um manangedbean para listar e outro para editar, como passaria esse objeto de um para o outro?

Bem da forma como eu faço, por exemplo o ManagedBean para manipular o cliente é o mesmo que lista, edita e etc. Ou seja o seu próprio ManagedBean controla tudo. Entendeu?

No momento não estou trabalhando com WEB, mas tenho um exemplo aqui de uma matéria da faculdade que tive JSF2

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */

import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;

import entidade.Produto;
import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.EntityTransaction;
import util.JPA;

/**
 *
 * @author curso
 */
@ManagedBean
@SessionScoped
public class ProdutoBean {

    private Produto produto = new Produto();
    private String msg;
    private String erro;
    private List<Produto> produtos;

    /** Creates a new instance of ProdutoBean */
    public ProdutoBean() {
    }

    public Produto getProduto() {
        return produto;
    }

    public void setProduto(Produto produto) {
        this.produto = produto;
    }

    public String getMsg() {
        return msg;
    }

    public void setMsg(String msg) {
        this.msg = msg;
    }

    public String getErro() {
        return erro;
    }

    public void setErro(String erro) {
        this.erro = erro;
    }

    public List<Produto> getProdutos() {
        return produtos;
    }

    public void setProdutos(List<Produto> produtos) {
        this.produtos = produtos;
    }

    public String novo() {
        produto = new Produto();
        return null;
    }

    public String editar() {

        return "index";
    }

    public String listar() {
        EntityManager em = JPA.getEM();
        produtos = em.createNamedQuery("Produto.findAll").getResultList();

        return "listarProdutos";
    }

    public String salvar() {
        //deve-se realizar a validação de negócio do produto
        msg = "";
        EntityManager em = JPA.getEM();
        EntityTransaction tx = em.getTransaction();
        tx.begin();

        if (produto.getId() == null) {
            em.persist(produto);
        } else {
            produto = em.merge(produto);
        }

        tx.commit();
        em.close();
        msg = "OK!";

        return null;
    }
}

Os créditos são do meu professor…

entendi…
mas da listagem para a edição tu muda de página correto…
e… o valor do objeto selecionado não se perde nessa mudança de pagina? apesar de estar usando o mesmo MB?

Use esse atributo no bean

@SessionScoped

De uma olhada no exemplo que postei.

f2pro, postei um exemplo aqui que pode te ajudar.
Veja na página usuario.xhtml como utilizei o botão alterar.
Pra saber qual foi o registro selecionado na datatable, você vai usar algo assim

<f:setPropertyActionListener target="#{bean.seuObjeto}" value="#{registro}" />

lucas_carvalho100:

Use esse atributo no bean

@SessionScoped

De uma olhada no exemplo que postei.

hm… SessionScoped

boa…
vlw a todos pela ajuda…
vou estudar o que me passaram…
obrigado mesmo…

Bad news …
Não use um ManagedBean para controlar dois templates.
Não use o SessionScoped a não ser q vc realmente saiba o q está fazendo. Uma dica: não use-o para esse tipo de coisa.

Existem muitas outras maneiras de se fazer isso.

aluisiodsv:

Bad news …
Não use um ManagedBean para controlar dois templates.
Não use o SessionScoped a não ser q vc realmente saiba o q está fazendo. Uma dica: não use-o para esse tipo de coisa.

Existem muitas outras maneiras de se fazer isso.

Bad, bad news…
Bom cara essa parte de usa um MB para cada template já estava utilizando, mas onde posso obter informações dessa segunda parte que tu falo, de nao usar SessionScoped e passar o objeto de outra maneira?
eu realmente ia utilizar o SessionScoped mas pensei que num certo momento o servidor estaria cheio dessas sessions e explodir :shock:

Eu faço essa pergunta pois, nos tutorias que vi pela net, a grande maioria ensinava com poucos atributos, logo, usavam para editar um dialog e, portanto, não mudando de páginas…

Abraços…

Está usando jBoss Seam ? Ou apenas JSF 2.0?

Apenas JSF 2.0 e GlassFish

<f:param> é uma maneira.

Não trabalho com JSF 2.0 mas este é um exemplo:

http://www.mkyong.com/jsf2/jsf-2-param-example/

• JSF view parameters
  Starting with JSF 2.0, a new set of parameters is available. This set is named view
  parameters. These parameters are specified as metadata to the page and can be
  included in the generated URLs as you will see in this recipe.
  Getting ready
  We have developed this recipe with NetBeans 6.8, JSF 2.0, and GlassFish v3. The JSF 2.0
  classes were obtained from the NetBeans JSF 2.0 bundled library.

How to do it…
The official API documentation describes a view parameter as an entity represented by the
javax.faces.component.UIViewParameter component class that acts as a declarative
binding (using an EL value expression) between a request parameter and a model property.
A view parameter is commonly specified in the f:metdata tag using the f:viewParam
tag (we say that the parameters are specified as metadata to the page), as in the following
example (notice that this parameter is defined in page2.xhtml?we will navigate to this page
from page1.xhtml):

<f:metadata>
  <f:viewParam id="id" name="viewParam" value="#{bean.bye}"/>
</f:metadata>

Now, we will “exploit” this view parameter from a h:link hyperlink. This hyperlink is defined in
page1.xhtml like this:

<h:link includeViewParams="true" outcome="page2.xhtml" value="HelloToYouByeToHer">
  <f:param name="helloparam" value="#{bean.hello}"/>
</h:link>

Notice that we have set the includeViewParams attribute to true on h:link (this is true
for h:button also). This will have a great effect because the UIViewParameters will be a
part of the generated URL. You also may use the include-view-params attribute on the
redirect element of a navigation case set to true to obtain the same effect.
The result of this component is listed next?even if you never activate the component. Note
that this URL can be bookmarked from the first moment: http://localhost:8080/JSF_
view_parameters/faces/page2.xhtml?helloparam=Adrian&viewParam=Mary.
The bean responsible for the values of helloparam and viewParam is:
package beans;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
@ManagedBean
@SessionScoped
public class Bean {
  private String hello = "Adrian";
  private String bye = "Mary";
  public Bean() {
  }
  public String getBye() {
    return bye;
  }
  public void setBye(String bye) {
    this.bye = bye;
  }
  public String getHello() {
    return hello;
  }
  public void setHello(String hello) {
    this.hello = hello;
  }
}

Keep in mind that the view parameters that are included in the generated
URL will be those of the view being navigated to.
Now, going deeper into the view parameters world, we notice that JSF 2.0 process the view
parameters using the standard post-back processing lifecycle, which allows us to attach
converters and validators to them. For example, we indicate that our view parameter is
required as shown next:

<f:metadata>
  <f:viewParam id="id" name="viewParam" value="#{bean.bye}" required="true" requiredMessage="This parameter is a must!"/>
</f:metadata>

Or here is a more complex example, with a validator attached:

<f:metadata>
  <f:viewParam id="id" name="id" value="#{bean.property}" required="true" requiredMessage="?" converterMessage="?" validatorMessage="?">
    <f:validateLongRange minimum="1"/>
  </f:viewParam>
</f:metadata>

Usage of f:metadata can be extended to Facelets templating features and
view events, and is not specific only to view parameters. There’s a lot more to
view parameters than what was shown before.
How it works…
We can’t say that the previous examples are self-explanatory, but we also can’t explain here
the secrets behind the scenes because we would then have a very large section. Anyway,
what we can do is to make you aware that the view parameters provide information about how
request parameters should be handled when a view is requested or linked to, which means
that the view parameters are not rendered themselves. So, we say that they are part of the
view’s meta-model and described using metadata, f:metadata.
See also
The code bundled with this book contains a complete example of this recipe. The project can
be opened with NetBeans 6.8 and it is named: JSF_view_parameters.