Nested conversations nested relationships

[monkeyden]

Looking for a little guidance to implement a recursive EntityHome, via nested conversations. 

I have a an object, let's call it ObjectA.  It has a property named parentId.  This property can be null, signifying that it's at the top level of the relationship, or it can have some value, signifying that it has a parent.  An ObjectA can have a parent, and also be a parent itself.

I am using EntityQuery and EntityHome to allow the user to search and add/edit, respectively.  The initial search page shows all top level ObjectAs.  The add/edit page shows the selected ObjectA and a list of it's child ObjectAs, allowing the user to click on the children and drill down further.  It also has a cancel button, allowing the user to go back to the previously selected ObjectA.  I'm assuming there would be nested convos, allowing the user to pop the current convo and go back to the previous.  I'm also beginning to wonder if I need some controller to manage the EntityHomes, since the same instance appears to be reused. 

Further, the page needs to be RESTful, so I tried adding a page param to pages.xml but it seems to call that method several times and eventually with a null value.

I suspect there isn't a lot of code to get it done but I haven't figured out the right combination yet.  Has anyone implemented this sort of recursive view/add/edit pattern using EntityHome?  Was it necessary to dedicate a controller solely for the purpose of beginning nested convos and creating EntityHomes?

Thanks for any help.

[luxspes]

Kyle Burke wrote on Apr 06, 2009 04:14:


Looking for a little guidance to implement a recursive EntityHome, via nested conversations. 

I recommend you to stay away from nested conversations (and I am not the only one). But if you still want to try first thing to know is to avoid the ManagedEntityInterceptor (JBSEAM-3493). The good news is that it is now disabled by default, if you enabled it, and want to work with nested transactions, disable it first.

I have a an object, let's call it ObjectA.  It has a property named parentId.  This property can be null, signifying that it's at the top level of the relationship, or it can have some value, signifying that it has a parent.  An ObjectA can have a parent, and also be a parent itself. But be alert, because JBSEAM-3454, ready to rip you to shreds.

Yes, yes, been there, tried to do that ;-).

I am using EntityQuery and EntityHome to allow the user to search and add/edit, respectively.  The initial search page shows all top level ObjectAs.  The add/edit page shows the selected ObjectA and a list of it's child ObjectAs, allowing the user to click on the children and drill down further.  It also has a cancel button, allowing the user to go back to the previously selected ObjectA.  I'm assuming there would be nested convos, allowing the user to pop the current convo and go back to the previous.

If it only worked like that. The third pitfall is the conversation vaccum (JBSEAM-3484). Try to avoid falling on it, it is a bottomless pit ;-) .

  I'm also beginning to wonder if I need some controller to manage the EntityHomes, since the same instance appears to be reused. 

IMHO EntityHomes/Queries are IMO unable to nicely deal with recursive/nested stuff. The next pitfall is CRUD, seam-gen model is incomplete and therefore, it fails to do a proper job (JBSEAM-3903).

Further, the page needs to be RESTful, so I tried adding a page param to pages.xml but it seems to call that method several times and eventually with a null value.

I suspect there isn't a lot of code to get it done but I haven't figured out the right combination yet.  Has anyone implemented this sort of recursive view/add/edit pattern using EntityHome?  Was it necessary to dedicate a controller solely for the purpose of beginning nested convos and creating EntityHomes?

Okey, I am guessing that a convo is a conversation. I made it work, but didn't use nested conversations, you just need to alter the Urls so that you remember by url the id of the parent object, of course, since JPA/Hibernate does not support ids for new will be persisted objects you can only do this if your parent is already saved, which means you have a 2-level limit (you can not drill down further unless you save first, or you implement you own temporary object id for un-persisted objects). I think this is the kind of problem for which server side restful stuff is a bad idea, stateful conversational stuff should help, but so far it does not.

Thanks for any help.

Please vote for all the JIRA issues referenced and maybe this will easy to do one day.