Cut/paste example

From: Gili (cowwo..bs.darktech.org)
Date: Mon Sep 19 2005 - 14:16:52 EDT

  • Next message: Kevin Menard: "Re: Running tests"

    Hi,

            I bring this up in the devel mailing list because it's a real use-case
    I'm dealing with and it also demonstrates a situation that might benefit
    from a registered non-inserted state for DataObjects (so they can hold
    relationships without being inserted).

            I've got a TransferHandler (for drag and drop) and one of the
    operations I need to support is cut/paste. The way the algorithm works,
    you must first delete the node, then you can paste it as many times as
    you want. Now, if your node consist of actual database items, you want
    to delete items from the underlying database when a cut occurs (because
    the user can quit before ever pasting), but then when it comes time to
    paste you're left with nothing to copy from. Normally, you'd want to
    copy your item into the clipboard, delete the original, then when it
    comes time to paste you just copy from your clipboard into the JTree or
    whatever you pasted into. This seems to imply that the "copy" in the
    clipboard needs to be a registered, non-inserted DataObject (which is
    not currently possible) because (1) you want to maintain your
    relationships and (2) you don't want to insert the DO if someone invokes
    context.commitChanges()

            One workaround I've been able to come up with is to register the
    clipboard DOs using a different DataContext than the one being used in
    the JTree. Since I never give out references to this DC, no one will be
    able to commitChanges().

            Andrus, this question related to "linking two unregistered
    CayenneDataObjects" which was brought up recently on the list. I wanted
    to ask if people use non-registered objects for anything in Cayenne and
    whether they would be negatively affected by the following proposal.
    What are you thoughts on moving from:

    1) unregistered DO
    2) registered, inserted DO

            to

    1) registered, non-inserted DO
    2) registered, inserted DO

            By forcing all DOs to be registered we would solve the "linking
    unregistered objects" problem. What are your thoughts on this?

    Thank you,
    Gili

    -- 
    http://www.desktopbeautifier.com/
    



    This archive was generated by hypermail 2.0.0 : Mon Sep 19 2005 - 14:16:53 EDT