Re: Proper use of nesting DataContexts in RCP

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Fri Dec 12 2008 - 02:02:50 EST

  • Next message: Borut Bolčina: "Re: caching documentation"

    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 of
    > EDITORCHILDCTXT.
    >
    > 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
    > DIALOGCHILDCONTEXT, and CONCEPT1 is in EDITORCHILDCTXT. The desired
    > 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
    > ==================================
    > lawger..mail.com
    >
    >
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Fri Dec 12 2008 - 02:03:47 EST