Question

I have a table of Items, and in each row there is a link that forwards to the edit item page. To load data in the edit page I need the managed bean in request scope (if I put it in view scope I loose data in the forward).

To use ajax in the edit page I need the managed bean in view Scope due to some values I must keep. If I were working with JSF 1.0 and RichFaces I would do it with request scope and a4j:keepalive.

How do I get this funcionality with PrimeFaces and JSF 2.0 or how can I redefine the interface to get this?

Ok, finally based on the post below this is what worked for me:
CommandButton in the Items table:

<o:commandButton id="editButton"
action="#{itemTableMB.editItem(item.id)}" styleClass="botonTabla">
<h:graphicImage styleClass="imagenBotonTabla" url="/resources/images/icons/pencil.png"/>  
</o:commandButton> 

Action in the managed bean:

public String editItem(Integer id){
return "/pages/items/edit.xhtml?faces-redirect=true&id="+id;
}

edit.xhtml:

<f:metadata>
  <f:viewParam id="id" name="id" value="#{itemMB.item.id}"    required="true">
  </f:viewParam>
  <f:event type="preRenderView" listener="#{itemMB.loadItem}" />
</f:metadata> 

Listener in itemMB:

public void loadItem(){
      this.item = this.itemManager.get(this.item.getId());
}

Answer 1

To load data in the edit page I need the managed bean in Request scope (If I put it in view scope I loose data in the forward).

Are you using a navigation rule (or implicit navigation) without a redirect?

One solution would be to put backing beans of both the “table of items”-page and the “edit item”-page in view scope, and then go from the first to the second one directly via a GET request (e.g. using <h:link>) or a POST/redirect with a request parameter representing the row on which the user clicked.

Use <f:viewParam> on the second page to conveniently convert the request parameter back to an entity representing the item being edited.

If you were indeed using navigation without redirect, then this has the additional benefit that you won’t suffer from the notorious ‘one-URL-behind-problem’, which can be rather confusing to users of your application and be a nightmare for support.