Home » Modeling » GMF (Graphical Modeling Framework) » seeking design advice: editing domains and resource sets
| seeking design advice: editing domains and resource sets [message #156519] |
Fri, 19 October 2007 13:37  |
Eclipse User |
|
|
|
Originally posted by: NOSPAM.xyz.com
Hello fellows,
Working on my application I reached a stage where my own understanding of
the transaction mechanisms in
GMF is way not enough, so I count on your advice.
My editor will have to deal with a deep hierarchy of Nodes and SubDiagrams.
SubDiagrams may contain Nodes and other subDiagrams and so on ....
Please take a look at the attached picture.
The domain model is very simple:
A Field which contains Blocks and other Fields.
The element of my top-level Diagram and of any subDiagram is of type Field.
My problem, from a user convenience point of view, is that the top-level
Diagram can quickly get over-crowded.
So, the subDiagrams should occupy as little real-estate as possible, until
they are selected and edited.
I plan to address this issue by providing 3 possible states in which a
subDiagram can be:
* closed
* partially expnded
* fully expanded: edited in a separate Tab of a MultiPageEditorPart
Up to now I implemented the first two. A closed subDiagram is like a
thumbnail - just a
notational Node that shows a picture of its non-editable contents.
A partially expanded subDiagram is a Node whose Edit Part has a compartment
equiped
with those neat scroll bars, so some editing of its content is allowed. It
is not very convenient, though,
it is like looking at the landscape through a keyhole.
I almost have the "fully expanded" thing working too, at least if we ignore
the Exceptions :-)
I can take the Field domain element from a subDiagram-to-be-fully expanded,
save it in a new resource
and open a new DiagramEditor on it in a new Tab. There I can edit it all
right and at the end say "close Tab".
Here is where the problems start.
The edited content is correctly put back in the original subDiagram Node in
the first / top-level Tab
where all that started, but...
But when I try to move / whatever the children (that were in the new Tab) of
that subDiagram Node a transaction related Exception gets thrown.
Caused by: java.lang.IllegalStateException: Cannot modify resource set
without a write transaction
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ssertWriting(TransactionChangeRecorder.java:322)
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ppendNotification(TransactionChangeRecorder.java:284)
.....
at
org.eclipse.gmf.runtime.diagram.ui.commands.SetBoundsCommand .doExecuteWithResult(SetBoundsCommand.java:103)
I guess I mess with the TransactionalEditingDomain.
Currently the two resources - the original and the temporary one - belong
to the same ResourceSet.
So my question is: What is the best design - single or different
TransactionalEditingDomain and / or ResourceSet - when we deal with
this use case:
1) Put a Node in a DiagramEditor, add children Nodes to it.
2) Take the domain elenemt of that Node, save it in a
temporary resoursce and open a new instance
of the same DiagramEditor in a new multi-page editor's Tab
3) Edit it there - add / remove children Nodes
4) Close the Tab + delete the temporary resoursce + put the edited children
back in the original Node
Cheers,
Theo
|
|
|
| Re: seeking design advice: editing domains and resource sets [message #156532 is a reply to message #156519] |
Fri, 19 October 2007 16:42  |
| Eclipse User |
|
|
|
Originally posted by: NOSPAM.xyz.com
Sorry, forgot the picture
"Theo" <NOSPAM@xyz.com> wrote in message
news:ffapsg$krh$1@build.eclipse.org...
> Hello fellows,
>
> Working on my application I reached a stage where my own understanding of
> the transaction mechanisms in
>
> GMF is way not enough, so I count on your advice.
>
>
>
> My editor will have to deal with a deep hierarchy of Nodes and
> SubDiagrams.
>
> SubDiagrams may contain Nodes and other subDiagrams and so on ....
>
> Please take a look at the attached picture.
>
>
>
> The domain model is very simple:
>
> A Field which contains Blocks and other Fields.
>
> The element of my top-level Diagram and of any subDiagram is of type
> Field.
>
>
>
> My problem, from a user convenience point of view, is that the top-level
> Diagram can quickly get over-crowded.
>
> So, the subDiagrams should occupy as little real-estate as possible, until
> they are selected and edited.
>
> I plan to address this issue by providing 3 possible states in which a
> subDiagram can be:
>
> * closed
>
> * partially expnded
>
> * fully expanded: edited in a separate Tab of a MultiPageEditorPart
>
>
>
> Up to now I implemented the first two. A closed subDiagram is like a
> thumbnail - just a
>
> notational Node that shows a picture of its non-editable contents.
>
>
>
> A partially expanded subDiagram is a Node whose Edit Part has a
> compartment
> equiped
>
> with those neat scroll bars, so some editing of its content is allowed. It
> is not very convenient, though,
>
> it is like looking at the landscape through a keyhole.
>
>
>
> I almost have the "fully expanded" thing working too, at least if we
> ignore
> the Exceptions :-)
>
> I can take the Field domain element from a subDiagram-to-be-fully
> expanded,
> save it in a new resource
>
> and open a new DiagramEditor on it in a new Tab. There I can edit it all
> right and at the end say "close Tab".
>
> Here is where the problems start.
>
> The edited content is correctly put back in the original subDiagram Node
> in
> the first / top-level Tab
>
> where all that started, but...
>
> But when I try to move / whatever the children (that were in the new Tab)
> of
> that subDiagram Node a transaction related Exception gets thrown.
>
>
>
> Caused by: java.lang.IllegalStateException: Cannot modify resource set
> without a write transaction
>
> at
> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ssertWriting(TransactionChangeRecorder.java:322)
>
> at
> org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ppendNotification(TransactionChangeRecorder.java:284)
>
> ....
>
> at
> org.eclipse.gmf.runtime.diagram.ui.commands.SetBoundsCommand .doExecuteWithResult(SetBoundsCommand.java:103)
>
>
>
> I guess I mess with the TransactionalEditingDomain.
>
> Currently the two resources - the original and the temporary one - belong
> to the same ResourceSet.
>
>
>
> So my question is: What is the best design - single or different
>
> TransactionalEditingDomain and / or ResourceSet - when we deal with
>
> this use case:
>
>
>
> 1) Put a Node in a DiagramEditor, add children Nodes to it.
>
> 2) Take the domain elenemt of that Node, save it in a
>
> temporary resoursce and open a new instance
>
> of the same DiagramEditor in a new multi-page editor's Tab
>
> 3) Edit it there - add / remove children Nodes
>
> 4) Close the Tab + delete the temporary resoursce + put the edited
> children
>
> back in the original Node
>
>
>
> Cheers,
>
> Theo
>
>
>
>
>
>
>
>
>
>
|
|
|
| sorry for the formatting [message #156580 is a reply to message #156519] |
Sat, 20 October 2007 09:31 |
| Eclipse User |
|
|
|
Originally posted by: NOSPAM.xyz.com
Hello fellows,
working on my application I reached a stage where my own understanding
of the transaction mechanisms in GMF is way not enough, so I count on your
advice.
My editor will have to deal with a deep hierarchy of
Nodes and SubDiagrams. SubDiagrams may contain Nodes
and other subDiagrams and so on .... Please take a look
at the attached picture.
The domain model is very simple:
A Field which contains Blocks and other Fields.
The element of my top-level Diagram and of any subDiagram is of type Field.
My problem, from a user convenience point of view, is that
the top-level Diagram can quickly get over-crowded.
So, the subDiagrams should occupy as little real-estate as
possible, until they are selected and edited.
I plan to address this issue by providing 3 possible states
in which a subDiagram can be:
* closed
* partially expnded
* fully expanded: edited in a separate Tab of a MultiPageEditorPart
Up to now I implemented the first two.
A closed subDiagram is like a thumbnail - just a
notational Node that shows a picture of its non-editable contents.
A partially expanded subDiagram is a Node whose Edit Part
has a compartment equiped with those neat scroll bars, so some
editing of its content is allowed. It is not very convenient, though,
it is like looking at the landscape through a keyhole.
I almost have the "fully expanded" thing working too,
at least if we ignore the Exceptions :-)
I can take the Field domain element from a subDiagram-to-be-fully expanded,
save it in a new resource and open a new DiagramEditor on it in a new Tab.
There I can edit it all right and at the end say "close Tab".
Here is where the problems start. The edited content is correctly put back
in the original subDiagram Node in the first / top-level Tab
where all that started, but...
But when I try to move / whatever the children (that were in the new Tab)
of that subDiagram Node a transaction related Exception gets thrown.
Caused by: java.lang.IllegalStateException: Cannot modify resource set
without a write transaction
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ssertWriting(TransactionChangeRecorder.java:322)
at
org.eclipse.emf.transaction.impl.TransactionChangeRecorder.a ppendNotification(TransactionChangeRecorder.java:284)
.....
at
org.eclipse.gmf.runtime.diagram.ui.commands.SetBoundsCommand .doExecuteWithResult(SetBoundsCommand.java:103)
I guess I mess with the TransactionalEditingDomain.
Currently the two resources - the original and the temporary one -
belong to the same ResourceSet.
So my question is: What is the best design - single or different
TransactionalEditingDomain and / or ResourceSet - when we deal with
this use case:
1) Put a Node in a DiagramEditor, add children Nodes to it.
2) Take the domain elenemt of that Node, save it in a
temporary resoursce and open a new instance
of the same DiagramEditor in a new multi-page editor's Tab
3) Edit it there - add / remove children Nodes
4) Close the Tab + delete the temporary resoursce + put the edited children
back in the original Node
Cheers,
Theo
|
|
|
Goto Forum:
Current Time: Wed Jul 16 20:10:03 EDT 2025
Powered by FUDForum. Page generated in 0.14705 seconds |
Home