Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » Problem using Imported Elements in operations
Problem using Imported Elements in operations [message #1015694] Fri, 01 March 2013 14:10 Go to next message
Paul Benedict is currently offline Paul Benedict
Messages: 3
Registered: March 2013
Junior Member
Using the UML Model Editor, I imported the 5 provided primitives of UML: Boolean, Integer, Real, String, UnlimitedNatural.

It was my intention to use Boolean as the type of a Parameter (return value of an Operation). However, when I am using my Papyrus Editor, I am unable to select these imported elements for the parameter type. They show up in the Type Browser, but the OK button is grayed out.

Am I doing something wrong? I do think I should be able to select these. Thanks!
Re: Problem using Imported Elements in operations [message #1015768 is a reply to message #1015694] Sat, 02 March 2013 09:35 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 768
Registered: July 2009
Senior Member
Hi, Paul,

I don't have this problem in the Kepler M5 milestone, neither using a
package import nor individual element imports. Which version of
Papyrus are you using? Do you see any exceptions in the log when you
either import the library elements or when you attempt to set the
parameter type?

Did you import the UML Primitive Types library package, or individually
its contained types?

Cheers,

Christian


On 2013-03-01 19:50:14 +0000, Paul Benedict said:

> Using the UML Model Editor, I imported the 5 provided primitives of
> UML: Boolean, Integer, Real, String, UnlimitedNatural.
>
> It was my intention to use Boolean as the type of a Parameter (return
> value of an Operation). However, when I am using my Papyrus Editor, I
> am unable to select these imported elements for the parameter type.
> They show up in the Type Browser, but the OK button is grayed out.
>
> Am I doing something wrong? I do think I should be able to select
> these. Thanks!
Re: Problem using Imported Elements in operations [message #1016058 is a reply to message #1015768] Mon, 04 March 2013 13:47 Go to previous messageGo to next message
Paul Benedict is currently offline Paul Benedict
Messages: 3
Registered: March 2013
Junior Member
Christian, I imported the contained types individually. It did not occur to me to try the Kepler M5 Developer Build. So I just installed it.... It works, but I was almost ready to declare it didn't work because the process is so unintuitive. Here's my drilldown to get the OK button working: Model > elementImport > Element Import Boolean > importedElement > EDataType Boolean. That's rather complex! Why isn't selecting Boolean under the first "elementImport" good enough?

PS: When I click on "Edit Parameter", the Cancel button never highlights. I can't get any edit component to activate the button. This is very much a bug. I don't think the button's listener is picking up any change events.... And if if I click the X in the dialog's title bar, my changes are saved -- not discarded. Shocked

[Updated on: Mon, 04 March 2013 13:48]

Report message to a moderator

Re: Problem using Imported Elements in operations [message #1016072 is a reply to message #1016058] Mon, 04 March 2013 14:57 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 768
Registered: July 2009
Senior Member
Hi, Paul,

The first element labeled 'Boolean' is the ElementImport, which is the
model element representing the actual import relationship. I agree
that it is a lot of drilling down; it would be nice if the name filter
would actually select the first matching element that is a Type because
usually that's the one you want to choose.

The Cancel button not highlighting after you've made changes in the
dialog does sound like a bug. If it hasn't already been reported in
Bugzilla, I'm sure the team will welcome it!

cW


On 2013-03-04 18:47:20 +0000, Paul Benedict said:

> Christian, I imported the contained types individually. It did not
> occur to me to try the Kepler M5 Developer Build. So I just installed
> it.... It works, but I was almost ready to declare it didn't work
> because the process is so unintuitive. Here's my drilldown to get the
> OK button working: Model > elementImport > Element Import Boolean >
> importedElement > EDataType Boolean. That's rather complex! Why isn't
> selecting Boolean under the first "elementImport" good enough?
>
> PS: When I click on "Edit Parameter", the Cancel button never
> highlights. I can't get any edit component to activate the button. This
> is very much a bug. I don't think the button's listener is picking up
> any change events.
Re: Problem using Imported Elements in operations [message #1016215 is a reply to message #1016072] Tue, 05 March 2013 09:23 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille Letavernier
Messages: 439
Registered: February 2011
Senior Member
Quote:
This is very much a bug. I don't think the button's listener is picking up any change events.... And if if I click the X in the dialog's title bar, my changes are saved -- not discarded. Shocked


Well, yes, that's a bug. But not an easy one. The point is that opening an "Edit" dialog from the properties viaew actually opens n embedded properties view, with the exact same behavior, i.e. all modifications are applied instantly. The dialog is not transactional. So, I have disabled the cancel button to avoid mis-leading the user.

However, once the dialog is closed, you can still undo the modifications (One by one...)

We really need to open a transaction for each dialog, and a sub-transaction for each individual modification, but I'm not familiar enough with the EMF Transaction framework to do that.

So... that's a known issue, but I've no idea how it should be fixed.


And for the primitive types issue:

- Currently, in Papyrus, we're really close to the UML Metamodel. We lack shortcuts, which reduces the usability.
- The imported types suffer from a few bugs, especially the lack of support for imported types in the Reference History. As Christian suggested, we should also reveal the first matching element when there is a filter.
Re: Problem using Imported Elements in operations [message #1016229 is a reply to message #1016215] Tue, 05 March 2013 09:51 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 768
Registered: July 2009
Senior Member
Hi, Camille,

That's interesting ... I didn't know that this is how the dialog works.
Indeed, it certainly makes sense that there not be a cancel option in
such a a live editing scenario.

As it happens, I know a thing or two about EMF transactions. :-) The
most common usage that the API is designed for is execution of commands
on the EditingDomain's CommandStack. However, nested transactions are
supported if the client application is willing to mess around directly
with transactions (rather than just rely on the CommandStack creating
transactions implicitly).

Just thinking aloud for a minute, one possibility might be to start a
transaction when the modal dialog opens and mark the current top of the
command-stack (record which command is the current undo command).
Then, any edits performed in the dialog should actually be executed in
nested transactions. On cancel, the dialog would roll back the top
transaction and pop undo commands from the stack until it get backs to
the command that we found at the start. On OK, the dialog would commit
the top-level transaction.

Caveats:

- I don't know that the CommandStack offers this much flexibility
- all of the edits made in the dialog would still be separate commands on the
undo history; they wouldn't be composed into an "undo all edits of
the dialog"
- I don't know that the commands on the stack would actually undo cleanly

It might be worth some experimentation?

cW

On 2013-03-05 14:23:07 +0000, Camille Letavernier said:

> Quote:
>> This is very much a bug. I don't think the button's listener is picking
>> up any change events.... And if if I click the X in the dialog's title
>> bar, my changes are saved -- not discarded. Shocked
>
>
> Well, yes, that's a bug. But not an easy one. The point is that opening
> an "Edit" dialog from the properties viaew actually opens n embedded
> properties view, with the exact same behavior, i.e. all modifications
> are applied instantly. The dialog is not transactional. So, I have
> disabled the cancel button to avoid mis-leading the user.
>
> However, once the dialog is closed, you can still undo the
> modifications (One by one...)
>
> We really need to open a transaction for each dialog, and a
> sub-transaction for each individual modification, but I'm not familiar
> enough with the EMF Transaction framework to do that.
>
> So... that's a known issue, but I've no idea how it should be fixed.
>
>
> And for the primitive types issue:
>
> - Currently, in Papyrus, we're really close to the UML Metamodel. We
> lack shortcuts, which reduces the usability.
> - The imported types suffer from a few bugs, especially the lack of
> support for imported types in the Reference History. As Christian
> suggested, we should also reveal the first matching element when there
> is a filter.
Re: Problem using Imported Elements in operations [message #1016237 is a reply to message #1016229] Tue, 05 March 2013 10:29 Go to previous messageGo to next message
Camille Letavernier is currently offline Camille Letavernier
Messages: 439
Registered: February 2011
Senior Member
I had made some experiments last year on this topic, but I had the feeling I was manipulating too many "internals" (InternalTransactionalCommandStack/EditingDomain).

The first thing was to be able to determine the current state:

- If we're in the properties view (i.e. activeTransaction == null): direct edition with commands on the stack
- When we open a dialog, we actually execute a command on the stack, and this command opens the dialog
- Now we're in the dialog, activeTransaction != null. Instead of executing a Command on the stack, we need to start a nested transaction [Currently, execution of nested commands on the same command stack doesn't work]. If the dialog is canceled, we rollback this transaction; otherwise, we commit it.

I don't know if we actually need nested "commands", because in a dialog, we can't hit "ctrl + z" anyway (Although it would probably make sense in this case...).

There may be a problem with stacking commands in a single top-level transaction (with many sub-transactions): we will probably reach the command stack's limit at some point and un-committed commands may disappear from the stack.

Maybe it would make sense to have "nested command stacks" for nested transactions? I'm not sure if this would help... Each nested dialog would have its own command stack, with its own undo-redo support, and its own limit. When the dialog is canceled, we rollback the parent-command/transaction on the parent's stack, so even if the limit of the canceled dialog's stack has been reached, we don't use it anyway.


I think it is important to be able to call getCommandStack.execute(Command) in all cases (i.e. top-level transaction or nested transaction), so that we don't have to re-implement every call to this method.


Camille
Re: Problem using Imported Elements in operations [message #1016298 is a reply to message #1016237] Tue, 05 March 2013 17:22 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 768
Registered: July 2009
Senior Member
Hi, Camille,

On 2013-03-05 15:29:39 +0000, Camille Letavernier said:

>
> Maybe it would make sense to have "nested command stacks" for nested
> transactions? I'm not sure if this would help... Each nested dialog
> would have its own command stack, with its own undo-redo support, and
> its own limit. When the dialog is canceled, we rollback the
> parent-command/transaction on the parent's stack, so even if the limit
> of the canceled dialog's stack has been reached, we don't use it anyway.

This is exactly what I was thinking. Papyrus already supplies its own
editing domain, so it could create a CommandStack that supports
nesting. Essentially, the EditingDomain could have a stack of command
stacks.

The dialog could push a new command stack on the domain that just
executes commands in new nested transactions. That doesn't require
using internal transaction APIs. When the dialog has finished, it pops
the nested command-stack, which causes it to be disposed and the
previous (main) command-stack restored. That command-stack's top
command then has recorded the nested transaction with all of its
sub-transactions, which should (in theory) be undoable and redoable in
one step.

> I think it is important to be able to call
> getCommandStack.execute(Command) in all cases (i.e. top-level
> transaction or nested transaction), so that we don't have to
> re-implement every call to this method.

Absolutely. It would be absolutely a last resort to have two ways of
performing every edit: a command executed on the stack or directly. I
am hopeful that a stack-of-command-stacks approach could work.

cW
Re: Problem using Imported Elements in operations [message #1016464 is a reply to message #1016298] Wed, 06 March 2013 09:58 Go to previous message
Camille Letavernier is currently offline Camille Letavernier
Messages: 439
Registered: February 2011
Senior Member
Moving the discussion to Bugzilla:

402525: [Widgets / Transactions] Papyrus dialogs should be transactional
https://bugs.eclipse.org/bugs/show_bug.cgi?id=402525


Camille
Previous Topic:Allocation Table: Unresolved reference '/1
Next Topic:Mixed XMLResources and XMIResources in ModelSet?
Goto Forum:
  


Current Time: Wed Aug 20 22:22:44 EDT 2014

Powered by FUDForum. Page generated in 0.02386 seconds