| Why doesn't the Tool of a CombinedTemplateCreationEntry get used for drag and drop from the palette? [message #202176] |
Mon, 07 November 2005 15:14  |
Eclipse User |
|
|
|
Originally posted by: cmahoney.ca.ibm.com
Hello,
In GMF, we have a mechanism to allow clients to contribute the creation tool
to be used for their palette entries. We want to support DND from the
palette generically. Basically, I want my template (or creation factory?)
to be the creation tool itself because the client may have overridden
something in the creation tool (e.g. createTargetRequest(),
performCreation()). I am in the process of writing a
AbstractTransferDropTargetListener which will use the creation tool to
create the new shape (I am returning the tool as the template in the
CombinedTemplateCreationEntry).
Is there a reason why it wasn't done this way? Another benefit of using the
creation tool is that it already has the selectAddedObject() logic and this
wouldn't need to be written in the TemplateTransferDropTargetListener (in
theory).
Unfortunately, there are no public methods on the creation tool for which I
can easily create the shape in the location where the user dragged the
mouse. I think I will have to mimic mouse events or make
createTargetRequest() public in my parent creation tool class to support
this. I don't really like these ideas, any other suggestions?
Thanks,
Cherie
|
|
|
| Re: Why doesn't the Tool of a CombinedTemplateCreationEntry get used for drag and drop from the pale [message #202197 is a reply to message #202176] |
Mon, 07 November 2005 18:37  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
There are usually no reasons to subclass the CreationTool except to allow
the user to press a Cancel button and abort the creation and dismiss some
dialog that was displayed. Almost everything else can be done in the
factory, editpolicy, or command.
We should be selecting the created part. That's a bug.
"Cherie Mahoney" <cmahoney@ca.ibm.com> wrote in message
news:dknqun$6f2$1@news.eclipse.org...
> Hello,
>
> In GMF, we have a mechanism to allow clients to contribute the creation
> tool
> to be used for their palette entries. We want to support DND from the
> palette generically. Basically, I want my template (or creation factory?)
> to be the creation tool itself because the client may have overridden
> something in the creation tool (e.g. createTargetRequest(),
> performCreation()). I am in the process of writing a
> AbstractTransferDropTargetListener which will use the creation tool to
> create the new shape (I am returning the tool as the template in the
> CombinedTemplateCreationEntry).
>
> Is there a reason why it wasn't done this way? Another benefit of using
> the
> creation tool is that it already has the selectAddedObject() logic and
> this
> wouldn't need to be written in the TemplateTransferDropTargetListener (in
> theory).
>
> Unfortunately, there are no public methods on the creation tool for which
> I
> can easily create the shape in the location where the user dragged the
> mouse. I think I will have to mimic mouse events or make
> createTargetRequest() public in my parent creation tool class to support
> this. I don't really like these ideas, any other suggestions?
>
> Thanks,
> Cherie
>
>
|
|
|
| Re: Why doesn't the Tool of a CombinedTemplateCreationEntry get used for drag and drop from the pale [message #202200 is a reply to message #202176] |
Mon, 07 November 2005 18:46 |
| Eclipse User |
|
|
|
Originally posted by: none.unknown.com
CreationToolEntry, in its constructor, uses the CreationTool by default. If
you want to use another tool instead, use ToolEntry#setToolClass().
> Unfortunately, there are no public methods on the creation tool for which
I
> can easily create the shape in the location where the user dragged the
mouse.
I am not sure what you mean by this. This works just fine in the logic
example. The CreateRequest has the location information.
"Cherie Mahoney" <cmahoney@ca.ibm.com> wrote in message
news:dknqun$6f2$1@news.eclipse.org...
> Hello,
>
> In GMF, we have a mechanism to allow clients to contribute the creation
tool
> to be used for their palette entries. We want to support DND from the
> palette generically. Basically, I want my template (or creation factory?)
> to be the creation tool itself because the client may have overridden
> something in the creation tool (e.g. createTargetRequest(),
> performCreation()). I am in the process of writing a
> AbstractTransferDropTargetListener which will use the creation tool to
> create the new shape (I am returning the tool as the template in the
> CombinedTemplateCreationEntry).
>
> Is there a reason why it wasn't done this way? Another benefit of using
the
> creation tool is that it already has the selectAddedObject() logic and
this
> wouldn't need to be written in the TemplateTransferDropTargetListener (in
> theory).
>
> Unfortunately, there are no public methods on the creation tool for which
I
> can easily create the shape in the location where the user dragged the
> mouse. I think I will have to mimic mouse events or make
> createTargetRequest() public in my parent creation tool class to support
> this. I don't really like these ideas, any other suggestions?
>
> Thanks,
> Cherie
>
>
|
|
|
| Re: Why doesn't the Tool of a CombinedTemplateCreationEntry get used for drag and drop from the pale [message #202225 is a reply to message #202197] |
Mon, 07 November 2005 19:30 |
| Eclipse User |
|
|
|
Originally posted by: cmahoney.ca.ibm.com
Thanks. I guess the main issue is that we are subclassing the CreationTools
to provide different create requests than the standard GEF CreateRequest. I
may have to make createTargetRequest() public in our top-level CreationTool
so I can get the request from there.
- Cherie
"Randy Hudson" <none@us.ibm.com> wrote in message
news:dko6tv$oni$1@news.eclipse.org...
> There are usually no reasons to subclass the CreationTool except to allow
> the user to press a Cancel button and abort the creation and dismiss some
> dialog that was displayed. Almost everything else can be done in the
> factory, editpolicy, or command.
>
> We should be selecting the created part. That's a bug.
>
> "Cherie Mahoney" <cmahoney@ca.ibm.com> wrote in message
> news:dknqun$6f2$1@news.eclipse.org...
> > Hello,
> >
> > In GMF, we have a mechanism to allow clients to contribute the creation
> > tool
> > to be used for their palette entries. We want to support DND from the
> > palette generically. Basically, I want my template (or creation
factory?)
> > to be the creation tool itself because the client may have overridden
> > something in the creation tool (e.g. createTargetRequest(),
> > performCreation()). I am in the process of writing a
> > AbstractTransferDropTargetListener which will use the creation tool to
> > create the new shape (I am returning the tool as the template in the
> > CombinedTemplateCreationEntry).
> >
> > Is there a reason why it wasn't done this way? Another benefit of using
> > the
> > creation tool is that it already has the selectAddedObject() logic and
> > this
> > wouldn't need to be written in the TemplateTransferDropTargetListener
(in
> > theory).
> >
> > Unfortunately, there are no public methods on the creation tool for
which
> > I
> > can easily create the shape in the location where the user dragged the
> > mouse. I think I will have to mimic mouse events or make
> > createTargetRequest() public in my parent creation tool class to support
> > this. I don't really like these ideas, any other suggestions?
> >
> > Thanks,
> > Cherie
> >
> >
>
>
|
|
|
|
| Re: Why doesn't the Tool of a CombinedTemplateCreationEntry get used for drag and drop from the pale [message #202267 is a reply to message #202231] |
Mon, 07 November 2005 22:48 |
| Eclipse User |
|
|
|
Originally posted by: cmahoney.ca.ibm.com
Randy,
We're subclassing CreateRequest to identify different classifications of
create requests, primarily whether to create the underlying model element
and/or the diagram shape/connection. Our CreateRequests carry data
identifying the type of model element to be created and the type of diagram
shape/connection to be created. If a client needed more data in the
CreateRequest they would subclass our CreateRequest and the CreationTool
used by the palette. Maybe we could have accomplished this with a
CreationFactory, but we are not using these.
Some of our client CreationTools have probably been subclassed for the wrong
reason and instead an editpolicy should have been subclassed. However, I
still think there are valid reasons to override the CreationTool and this
behavior is also desired for the DND palette behavior. For example, we
overwrote performCreation() in the CreationTool to put the name of the shape
created on the diagram in edit mode instead of just selecting the shape. In
order to implement this same behavior after DND, I need to override
selectAddedObject() in the TemplateTransferDropTargetListener to do the
same. If our clients have subclassed CreationTool to select something
different after creation they would also need to override the
TemplateTransferDropTargetListener, but if the
TemplateTransferDropTargetListener delegates to the CreationTool then they
get this behavior in the DND for free.
I'm also coding for Eclipse now, so I'm trying to think more about where the
code should go (GEF or GMF). :-)
Thanks,
- Cherie
"Randy Hudson" <none@us.ibm.com> wrote in message
news:dkodkq$2qr$1@news.eclipse.org...
> What is the extra data that you are putting in the request?
>
> "Cherie Mahoney" <cmahoney@ca.ibm.com> wrote in message
> news:dko9vk$t77$1@news.eclipse.org...
> > Thanks. I guess the main issue is that we are subclassing the
> > CreationTools
> > to provide different create requests than the standard GEF
CreateRequest.
> > I
> > may have to make createTargetRequest() public in our top-level
> > CreationTool
> > so I can get the request from there.
> >
> > - Cherie
> >
>
|
|
|
| Re: Why doesn't the Tool of a CombinedTemplateCreationEntry get used for drag and drop from the pale [message #202284 is a reply to message #202267] |
Tue, 08 November 2005 03:15 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Cherie Mahoney" <cmahoney@ca.ibm.com> wrote in message
news:dkoliv$drm$1@news.eclipse.org...
> Randy,
>
> We're subclassing CreateRequest to identify different classifications of
> create requests, primarily whether to create the underlying model element
> and/or the diagram shape/connection. Our CreateRequests carry data
> identifying the type of model element to be created and the type of
> diagram
> shape/connection to be created. If a client needed more data in the
> CreateRequest they would subclass our CreateRequest and the CreationTool
> used by the palette. Maybe we could have accomplished this with a
> CreationFactory, but we are not using these.
It sounds like you could have put this extra info in the object type
parameter of the factory by making it some compound object. Or basically,
the type would be "model" or "view" or "model and connections", etc.
> Some of our client CreationTools have probably been subclassed for the
> wrong
> reason and instead an editpolicy should have been subclassed. However, I
> still think there are valid reasons to override the CreationTool and this
> behavior is also desired for the DND palette behavior. For example, we
> overwrote performCreation() in the CreationTool to put the name of the
> shape
> created on the diagram in edit mode instead of just selecting the shape.
> In
> order to implement this same behavior after DND, I need to override
> selectAddedObject() in the TemplateTransferDropTargetListener to do the
> same. If our clients have subclassed CreationTool to select something
> different after creation they would also need to override the
> TemplateTransferDropTargetListener, but if the
> TemplateTransferDropTargetListener delegates to the CreationTool then they
> get this behavior in the DND for free.
Using the creation tool for DND does not sound like the right thing. The
tool is a state machine for normal mouse events and there aren't any during
DND. Maybe you want something separated out from both the droptarget and the
tool for post-creation processing. But it sounds easy enough to duplicate
the behavior in two places.
> I'm also coding for Eclipse now, so I'm trying to think more about where
> the
> code should go (GEF or GMF). :-)
Great!
|
|
|
Powered by
FUDForum. Page generated in 0.04105 seconds
] 
Search
Help
Register
Login
Home
