Nested conversation for master-detail implementation

[lukebk]

We have implemented a master-detail and list set of pages.

The list pages shows a table with links (ice:commandButton) to the master entities:

public class MyMasterEntityList {
    ...
    @Begin( join \= true )
    public String newEntity() {
        ...
        return "new-entity";
    } 
}

[After opening the list] Conversation stack: 1, long running = false

In the MasterEntityHome page we have:

public class MyMasterEntityHome extends EntityHome\<MyMaster\> {

   @Begin( nested \= true );
   public String newDetail() {
      return "new-detail-entity";
   }

   @Begin( nested \= true );
   public String editDetail( MyDetailEntity detail ) {
      return "edit-detail-entity";
   }
   ... othere operations ...
   
}

[After opening the master page] Conversation stack: 2, long running = true, nested = false

public class MyDetailEntityHome extends EntityHome\<MyDetail\> {
    // Invoked when the uses presses "Cancel" in the master page
    @End( beforeRedirect \= true )
    public void close() {
        return "closed";
    }
    ... other stuff ...
}

[After opening the detail page] Conversation stack: 3, long running = true, nested = true, parent = 2

So far, so good. If I press the Cancel button (implemented as shown) I would expect the conversation stack to be something like this:

Conversation stack: 2, long running = true, nested = false

Instead, I get:

Conversation stack: 4, long running = false, nested = false

That is, instead of returning to the previous conversation in the stack, SEAM appears to lose the parent conversation and just start a new one from scratch (infact, my master entity home page is just empty).

Has anybody any idea about what's happening here or where may I be wrong?

[luxspes]

If this is for CRUD I recommend you to avoid nested Conversations completely, go for modalPanels, and please vote for JBSEAM-3903.

Conversations (specially nested ones) I have found are not really suited for CRUD, but they are really good for stuff that is pretty much read-only

[marios]

Thanks for the links: I've read them all and before giving any hope up, I'd like to submit this "simplified example" to the community:

1. I show the list.
2. I select an item: @Begin
   [The master pages open and the CID is shown on the URL]
  
<s:link value="View Entity" action="#{list.showEntity}"/>

@Name(\"list\")
public class EntityList {
     @Begin public void showEntity(){ }
}

3. I click on "Add child": @Begin( nested = true )
  
<h:commandLink action="#{parent.child}">Go to child</h:commandLink>

@Name(\"parent\") @Scope(ScopeType.CONVERSATION)
public class Parent {
     @Begin(nested \= true)
     public String child(){
         return \"child\";
     }

     @End(root \= true)
     public String die(){
          return \"/home.xhtml\";
     }

     @End(beforeRedirect\=true)
     public String endNested(){
           return \"/parent.xhtml\";
     }
}

   [The child form is shown, SEAM recognizes the master CID and the nested conversation CID ]

4. I press back on the child form
<s:button value="Back to parent" action="#{parent.endNested}"/>

[The nested conversation is killed but instead of returning to the old parent conversation, a new one is created (with long running = false)]

If I manually change the URL in order to point to the previous parent CID, I get my entity back, so I'm pretty lost: is this a bug or some kind of wanted behavior for nested conversations?!?

Thanks

[lukebk]

Looking for more infos in the forum I've found that someone else had the
same problem and it (seems) should be a bug:

JBSEAM-3406

However I've found a little work around that should works for now:
In the child element I've recovered the parent's conversation id

pid = Conversation.instance().getParentId();

Then when I press back button I pass this param trought pages.xml

<rule if-outcome="back">
           <redirect view-id="/entity/parent.xhtml" >
            <param name="cid" value="#{childHome.pid}"/>
           </redirect>
        </rule>

I hope this could help someone else...

Bye,
Luca