Home » Eclipse Projects » GEF » GEF DND support
| GEF DND support [message #248623] |
Fri, 24 April 2009 10:50  |
Eclipse User |
|
|
|
Hi Folks,
Based on the article here -
http://www.eclipse.org/articles/Article-GEF-dnd/GEF-dnd.html , I was able
to implement DND as part of my app and it seems to be working really fine.
I have a small problem that I would like to discuss and would highly
appreciate all the suggestions and comments, that would help me solve the
same.
Use case:Dragging files(Java classes and Interfaces) from the package
explorer and dropping them on the editor.
With my current implementation, I have a TransferDropTargetListener
registered with my viewer. Secondly, on dragging a java file, I create
"class" generation request, proper commands are generated and a class is
generated after dropping. I would like to achieve the same for an
Interface(Note: A separate request is needed for creating an Interface).
Now based on everything that I collect from the article,
1. My DropTargetListener can only generate a single request
(#createTargetRequest()). In my usecase, I have separate requests for
creating classes and Interfaces.
2. I tried registering a separate listener that is suppose to generate
request when an Interface is dropped. But then I have two separate
listeners registered. As described in the article - 1.... The listener
must be the first listener in the list to satisfy the first two conditions
of active listener, 2. ...If a target edit part is found, the listener is
enabled and the DelegatingDropTargetAdapter stops looking for listeners to
handle this event.
I would like to know whether the DND support in GEF(in particular for
FileTransfer) is applicable for solving problems like my usecase. If not,
are there any other approaches that may help in solving the problem. From
my side, I'll keep looking for the solution of the problem and if I find
one I'll write back to the group.
Looking forward for feedback.
Regards,
Neeraj
|
|
|
| Re: GEF DND support [message #248628 is a reply to message #248623] |
Fri, 24 April 2009 17:29  |
| Eclipse User |
|
|
|
Neeraj,
I'm not a GEF dnd expert, but wouldn't it be possible to use a single
request class, but use the type or other attributes to select the
appropriate policy?
I figure the problem is that in the listener, the createTargetRequest()
method is called before you have more information about the event. So
you can only create one (generic) request. The concrete information is
then passed not until handleDrop() gets called.
Have your tried to write two policies and check the request in
getTargetEditPart() not only by its type or class, but by the
information in that request?. The policy can then reject requests with
the wrong type (set in handleDrop()). As far as I've tested it,
understandsRequest(..) is not called afterwards, but you can check the
type in getTargetEditPart(). Let's say you have two policies, one for
classes, another for interfaces. Both can handle requests of the same
class. If you add a method to this request class, like isInterface(),
the getTargetEditPart() can return null if it is not the matching type.
Does this work?
Cheers,
Jens
|
|
|
| Re: GEF DND support [message #248647 is a reply to message #248623] |
Sat, 25 April 2009 15:02 |
| Eclipse User |
|
|
|
hi neeraj,
i had a problem with gef and drag and drop a couple days ago, too. my
approach to solve your problem would be to install a CreationFactory
depending on which item is dragged (class or interface). to do this i
would recommend to use your own transfer. create a class that extends
from SimpleObjectTransfer and you only have to initialize your
DragSourceListener and DropTragetListener with this new transfer (you
can do this in the constructor). remember that it is very common to
realize dnd transfers as a singleton. within your own transfer you can
define new methods with the help of them you can determine the selected
item from your navigator.
in the #createTargetRequest() you can use the methods of the your
transfer to decide which CreationFactory you want to set to your
(Creation)Request.
i hope this helps you.
cheers,
rené
Neeraj wrote:
> Hi Folks,
> Based on the article here -
> http://www.eclipse.org/articles/Article-GEF-dnd/GEF-dnd.html , I was able
> to implement DND as part of my app and it seems to be working really
> fine. I have a small problem that I would like to discuss and would
> highly appreciate all the suggestions and comments, that would help me
> solve the same.
> Use case:Dragging files(Java classes and Interfaces) from the package
> explorer and dropping them on the editor.
> With my current implementation, I have a TransferDropTargetListener
> registered with my viewer. Secondly, on dragging a java file, I create
> "class" generation request, proper commands are generated and a class is
> generated after dropping. I would like to achieve the same for an
> Interface(Note: A separate request is needed for creating an Interface).
> Now based on everything that I collect from the article,
> 1. My DropTargetListener can only generate a single request
> (#createTargetRequest()). In my usecase, I have separate requests for
> creating classes and Interfaces.
> 2. I tried registering a separate listener that is suppose to generate
> request when an Interface is dropped. But then I have two separate
> listeners registered. As described in the article - 1.... The listener
> must be the first listener in the list to satisfy the first two
> conditions of active listener, 2. ...If a target edit part is found, the
> listener is enabled and the DelegatingDropTargetAdapter stops looking
> for listeners to handle this event.
>
> I would like to know whether the DND support in GEF(in particular for
> FileTransfer) is applicable for solving problems like my usecase. If
> not, are there any other approaches that may help in solving the
> problem. From my side, I'll keep looking for the solution of the problem
> and if I find one I'll write back to the group.
>
> Looking forward for feedback.
>
> Regards,
> Neeraj
>
|
|
|
| Re: GEF DND support [message #248685 is a reply to message #248628] |
Sun, 26 April 2009 19:24 |
| Eclipse User |
|
|
|
Jens v.P. wrote:
Thanks Jens for your comments. Please find my comments in lined.
> Neeraj,
> I'm not a GEF dnd expert, but wouldn't it be possible to use a single
> request class, but use the type or other attributes to select the
> appropriate policy?
Yes, you are right, it is possible to have a single request class. In my
case,
I use "org.eclipse.gef.requests.CreateRequest" for both Interface and
Class. The type is same - "create child". The only point of divergence is
the way the object creation factory "behaves" in each case. The factory
associated with the Class creation request would return a Class instance
and in case of Interface would return an Interface instance. NOTE: The
factory class is the same.
> I figure the problem is that in the listener, the createTargetRequest()
> method is called before you have more information about the event. So
> you can only create one (generic) request. The concrete information is
> then passed not until handleDrop() gets called.
Yes again you are correct. Its no possible to get any information
regarding the exact operation unless the #handleDrop() gets called. And
this seems to be the real problem. If I were to get the event information
in #createTargetRequest(), I would have been in a better position to
decide the kind of request that should be created. Don't you think -
making the event type information available in the #createTargetRequest()
would be helpful.
> Have your tried to write two policies and check the request in
> getTargetEditPart() not only by its type or class, but by the
> information in that request?.
>The policy can then reject requests with the wrong type (set in
handleDrop()).
As far as I've tested it,
> understandsRequest(..) is not called afterwards, but you can check the
> type in getTargetEditPart(). Let's say you have two policies, one for
> classes, another for interfaces. Both can handle requests of the same
> class. If you add a method to this request class, like isInterface(),
> the getTargetEditPart() can return null if it is not the matching type.
> Does this work?
I haven't really tried it. Let me give it a try. BTW I was thinking of
something like - changing the Request instance in the #handleDrop(). By
this I mean, lets say I have earlier created a Class creation request
#createTargetRequest(), and then in #handleDrop(), it is revealed that an
Interface is dropped, I go ahead and create a Interface creation request
and assign this instance to the previously created Request instance. But
then would there be any side effects of this approach?? No idea need to
check. This may sound like a crazy hack. This is just a wild guess, lets
see if this works.
> Cheers,
> Jens
|
|
|
Goto Forum:
Current Time: Wed Mar 19 16:36:59 EDT 2025
Powered by FUDForum. Page generated in 0.04237 seconds |
Home