deep level nesting solution

[deanhiller2000]

We have an application that has a script which has questions which has widgets(variables) and rules and rules have expressions which have variables, etc. etc.  We get into deep level nesting.  Unfortunately, when saving a nested conversation, it saves off the line you took to get there and the parent and nested conversation are closed from what I understand, and the other paths of nested conversation are all dead.

ideally, I can be editing one of these scripts in one tab and another script in another tab.  My proposal is that we are going to refactor the code to follow a new pattern(as our code is just so buggy with current patterns).

We start with a list of questions, when a question is added or edited, we will persist the script if not already persisted and flush to database.  When add Widget to question, we will do the same, persist the question if needed and flush.  When save is chosen, we will persist and flush if needed and if cancel is chosen we will clear the entityManager.

1. The users definitely want save points as they get deep in the script, they want it to be saving for them
2. We have had much trouble with cancel where an ajax call may write data into a bean but then the user cancels but we can't end the conversation so saving at all those points above allows us to simply entityManager.clear the changes from the last save point.

Another pattern, I think a bit about is ending and starting a conversation at each of these points instead so cancel would then need to blow away the conversation and start a new one.  I am not sure how hard either of these patterns would be.  I just know from ALOT ALOT of experience now that when you have a table/list and you dig into that and have another table/list and dig into that and have another table/list, etc. it gets extremely complex with seam and I am trying to figure out the best pattern here.

We had one use case where you could save and validation failed in ACTION phase meaning values were applied to bean and then you cancelled and because the conversation still existed, the changes you cancelled from were saved to db at end of conversation.  The mgr.clear solves this, and keeping shorter conversations solves this as well.

I am not sure which approach to take yet.  We have not started done this path of design cleanup to follow one pattern or the other just yet. 

Any thoughts on this pattern?

thanks,
Dean

[nickarls]

Seam 2, I assume?

[deanhiller2000]

yes, 2.2...why? does v3 have some new solutions for this problem?

We did discover if you have small nested tables, and there are not too many fields in the child bean, doing an editable table is sometimes best(but you have to have a small amount of fields in the bean...and no nesting after that).

[deanhiller2000]

oh, shoot, just realized this was posted in seam 3...oops....but then, does this work any better in seam 3?  tough problem for sure.

[dan.j.allen]

Dean Hiller wrote on Mar 31, 2010 00:06:


oh, shoot, just realized this was posted in seam 3...oops....but then, does this work any better in seam 3?  tough problem for sure.

We are strongly considering leaving ad-hoc nested conversations out of Seam 3. Regardless of how intelligent we make the conversation system, the fact remains that nested conversations are inherently complex to deal with in the application. That complexity falls on the application developer's lap and frankly, I just think we are doing you a disservice providing that functionality.

A much better approach is to make an extremely usable and intelligent parallel conversation mechanism. This makes it easy for either the end user or the developer to step out of one conversation into another, then resume the first conversation when the second is complete. Notice I didn't use the word nested or parent-child. It would just be juggling flat conversations.

Notice I said we would leave out ad-hoc nested conversations. I do think that nested conversations work in the boundaries of a stateful pageflow. What's funny is that this is the one time in Seam 2 that nested conversations don't work. So basically, I think we need to reverse the emphasis.

You can follow along with the design of parallel conversations (aka workspaces) on the Seam 3 Faces Module page.

[nickarls]

I've been toying around with the idea of switching conversations mid-flight. Since access to the conversation context is actually just a fetch from a BeanStore (which is the current window on the conversation id into the session where the conversation stuff is kept) it should be possible to do if we link the ConversationImpl to the ConversationManager and on to the ConversationContext. Do you think it's feasible?

[deanhiller2000]

We have never used nested conversations....it was a for a specific use case like booking that we just don't have.

I would love having no nested conversations AND having a begin-conversation kill off any previous conversations if I set an attribute to do so(or better if it was the default).  I am tired of the you are already in a conversation exception when I don't really care..I want the previous one ended 99% of the time and making sure it is closed is sometimes really just a pain.

We do setup most of our main pages to end conversation when hit just in case there is anything open and we do on cancel have propagation=none.

[nickarls]

There will probably be some configurable option for nuke others. Instant switching of conversation would be nice to. So that you could e.g. @Inject an Instance with conversation scoped stuff and the in an action, iterate over active conversations and doing some magic for all instances.