Hi Bob, et al.,
So we both see the same problem.
I'll try to keep the discussion structured with ABC, but in reverse order:
C.
Before discussing your solution B, there is maybe another possibility, and
that is to start working with synonym UUIDs (let's call this solution C): if
an item is deleted, its UUID is stored as string, and when it needs to be
recreated, you will get a new UUID from MDR for the replacing element. The
idea is to maintain a set of sets of synonyms somewhere, and when other
elements need to be recreated by undo/redo, use the synonyms to reconnect
it.
Is this a feasible solution?
B.
Now about B - the principle: I do not recall any other application that
really works like this, except for the requirements management tool Doors,
but there must be others: If you delete something, it stays present in the
database, it is just not shown anywhere. Deleted items stay in the database
forever intentionally, unless you would "flush" them, another function.
In Doors, you even have a checkbox menu-item "show deleted" that makes them
visible. There must be other applications that use this pattern (databases,
filesystems, change-management tools, ...).
Persistence is not a problem, since the deleted items will never be
persisted anyhow.
BTW, Andrea's quest for a regular autosave may be gravely complicated - but
that should not stop us.
Now about B - the way to implement it: I do not know if you noticed, but in
fact you could use the old Trashcan (in the Project class) in ArgoUML
instead of the «deleted» stereotype: the story is the same, instead of
testing on the presence of the stereotype «deleted», you test on the
presence of the UUID in the Trashcan collection. I prefer to work with the
Trashcan above the «deleted».
A.
Your solution A is indeed not the way to go according my intuition, too.
A slightly different approach is to not store the complete repository, but
only the delta - err.. this is a wild idea (do not take too serious): store
the MDR repository in a Subversion repository after each and every change
(commit). This will make it "easy" to undo a few steps, by reverting to a
previous version. It may even open a solution for the multi-user problem.
I think the bottleneck for performance would be the conversion of the MDR
repository to XMI for every edit, and vice versa for every undo.
Not likely, this solution.
So, C needs some more thought - please help!
Otherwise B seems the only feasible way to me.
Regards,
Michiel
----- Original Message -----
From: "Bob Tarling" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, November 25, 2006 7:14 PM
Subject: Re: [argouml-dev] Demo undo for deleting an attribute
Hi Michiel
I was waiting till this link became available before discussing -
http://argouml.tigris.org/servlets/ReadMsg?list=commits&msgNo=275
Yes, I wanted really just to demonstrate why work has stalled here.
This is a complex problem. How can we record and reinstate all the
date from what may be a very complex delete.
The whole problem I think is that it is not possible to use an MDR
model element that is flagged as deleted and there is no way to clear
that flag. Instead of just keeping a reference to a model element and
then reinstating it we have to record all the properties of that model
element and create a new model element and then reinstate its
properties.
Doing such we still lose data such as the uuid.
There is a very similar problem with undo of create. Undoing would be
to delete the model element. But then redo should be able to recreate
that model element from before the undo.
I have no firm idea of the best way forward here but here are some
thoughts to be shot down
A) Our delete actions creates a copy of the entire repository each
time. Undo will reinstate that. I have no idea of performance impact
here but it doesn't sound like the most efficient way.
B) We make a major alteration to ArgoUML so that delete action does
not actually delete a model element. Instead it set a stereotype that
indicate that a model element is <<deleted>> as far as ArgoUML is
concerned. ArgoUML should treat such an element as if it doesn't
exist. Undo would be to remove the stereotype.
For (B) we would have to really delete these items on save. This is no
problem as save should be clearing the undo queue anyway.
Alternatives to (B) would be to move the elements into a different
model or repository (is that possible?).
Does any of this sound feasible?
Are there alternatives? Is there any undo technique built into MDR
(not that I've seen)?
Bob.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.16/551 - Release Date: 25/11/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
