deep level nesting solution
deanhiller2000 Mar 30, 2010 7:08 PMWe 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