cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lawrence Gerstley <>
Subject Re: Proper use of nesting DataContexts in RCP
Date Sun, 14 Dec 2008 23:02:30 GMT

I want to thank Andrus and all for this and all of the helpful  
answers. This is probably the most amicable and helpful group I've  
ever encountered.

This worked great. It's answered a big question that I had for awhile,  
and makes complete sense in the larger application scheme. Not being a  
Hibernate expert, I don't know if there is an equivalent concept to  
these nested contexts. I'm actually hopeful that there isn't, as I'm  
lately asked to defend using Cayenne over Hibernate, and this would be  
compelling. Gotta do more homework.

Many thanks again,

Lawrence Gerstley, Ph.D.

On Dec 11, 2008, at 11:02 PM, Andrus Adamchik wrote:

> Hi Lawrence,
>> Now, I don't think that I want to move CONCEPT1 to the  
>> DIALOGCHILDCONTEXT when I open the dialog--doesn't that mean that
> Actually that's exactly what you want to do. Don't think of it as  
> "move" though, think of it as getting a clone of the original  
> object, kind of like an SVN branch:
> CONCEPT1 localObject =  
> DataObjectUtils.objectForPk(DIALOGCHILDCONTEXT,  
> editorConcept1.getObjectId());
>> I'd have to move it back when I close said dialog?
> Here an SCM (SVN or other) analogy may also be useful. You won't be  
> moving it back, but rather merging your "branch" back to the parent.  
> This is not as scary as it sounds:
> DIALOGCHILDCONTEXT.commitChangesToParent();
> Andrus
> On Dec 12, 2008, at 7:26 AM, Lawrence Gerstley wrote:
>> Hello,
>> I've been using Cayenne quite successfully for sometime in creating  
>> my Eclipse RCP applications, but there is something that has  
>> flummoxed me for sometime, and was wondering about best practices.  
>> I've been creating a childDataContext (let's call in  
>> EDITORCHILDCTXT) every time I open up an EditorPart, so that it can  
>> use the Eclipse dirty/save model. This works fine, but a problem  
>> arises when I have dialogs in the editor. If I was editing, say, an  
>> ontological concept--let's call in CONCEPT, and it has 0-many  
>> PROPERTY, I might have a dialog window pop-up to create that  
>> property. The first thing I want to do in such a dialog is to  
>> create a CANDIDATE_PROPERTY, and add it to CONCEPT1. To do this, I  
>> would create a childDataContext (called DIALOGCHILDCTXT) as a child  
>> Now, ideally, I'd create and register a new PROPERTY and add it to  
>> the CONCEPT1 (something like "addToConceptProperties"). The  
>> problem, of course, is that the newly created PROPERTY1 is in  
>> behavior is to be able to use a <Cancel> button in the dialog,  
>> rollback and close DIALOGCHILDCONTEXT, losing the PROPERTY  
>> information, but leaving any changes to CONCEPT1 in EDITORCHILDCTXT  
>> intact, and commit only if the user confirms a save in that editor.
>> Now, I don't think that I want to move CONCEPT1 to the  
>> DIALOGCHILDCONTEXT when I open the dialog--doesn't that mean that  
>> I'd have to move it back when I close said dialog? Or do I want to  
>> get another copy of CONCEPT1 in the DIALOGCHILDCTXT to use for the  
>> addition of the new PROPERTY, and if I do that, how can I inform  
>> CONCEPT1 in the EDITORCHILDCTXT that it has a new PROPERTY, but not  
>> lose any of its other changes? Or, does this type of paradigm just  
>> not work here? Or, finally, am I just missing something terribly  
>> obvious, and have made a fool of myself. :)
>> I've gone back and read some of your 2007 discussions about  
>> connecting relationships between different contexts, and combed  
>> through the documentation, but really can't determine how to do  
>> this without forcing premature commits, breaking the editor dirty/ 
>> save paradigm. If you have any thoughts, I'd love to hear them!
>> Many thanks,
>> Lawrence
>> ==================================

View raw message