Re: [argouml-dev] Demo undo for deleting an attribute

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" <bob.tarling@xxxxxxxxx>
To: <dev@xxxxxxxxxxxxxxxxxx>
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: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx



--
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