| TemplateTransferDropTargetListener & CombinedTemplateCreationEntry - Problem [message #195231] |
Thu, 08 September 2005 15:13  |
Eclipse User |
|
|
|
Hi,
there's one thing that really bugs me, but let me first explain what I need
to do:
My palette shows different kinds of objects the user is supposed to be able
to place on the editor. Some of these objects can be created just by
passing the template object to a factory class.
Some objects in my palette represent objects already placed on the editor
and therefor require some additional data to be passed to the creation
factory. For this purpose I'm using a CombinedTemplateCreationEntry which
I'm passing a custom CreationFactory which takes the additional and needed
data as well as the template to create new models.
This works well for Point&Click-adding new objects to the editor.
When using Drag&Drop with a TemplateTransferDropTargetListener to add new
objects however, I need to implement the getFactory(Object template) method
- All information I'm getting to return a suitable CreationFactory is the
plain template which is not sufficient under certain circumstances.
Why does it not use the CreationFactory passed to the
CombinedTemplateCreationEntry - which can be parameterized with all the
information needed? This would even be the more expected behaviour.
Thanks for any comments!
Fabian
|
|
|
|
|
|
| Re: TemplateTransferDropTargetListener & CombinedTemplateCreationEntry - Problem [message #195425 is a reply to message #195289] |
Fri, 09 September 2005 14:17  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
> Hi Randy,
>
> that would surely be possible, is not a clean solution though.That'd make
> me
> pass two CreationFactories to the CombinedTemplateCreationFactory - one
> which is used for DragNDrop the other for Point&Click.
Could it not just be the same factory? We'll add a new constructor in 3.2
that takes just a factory, and uses it as the template.
> What I'm missing is a getFactory() method in
> org.eclipse.gef.palette.CreationToolEntry - or for future releases a
> getToolProperty(Object key). There would then be no need for the abstract
> method getFactory(Object template) in TemplateTransferDropTargetListener,
> instead it could return the CreationFactory the palette entry was equipped
> with... something like that (not tested):
>
> EditPart editPart =
> (EditPart)getViewer().getSelectedEditParts().get(0);
> Object model = editPart.getModel();
> if (model instanceof CombinedTemplateCreationFactory)
> return
> ((CombinedTemplateCreationEntry)model).getFactory();
> return null;
>
> This is the way the templates get set in
> TemplateTransferDragSourceListener.
> Or: the CreationFactory could be carried in the TemplateTransfer just like
> the template.
So, we could also make the drop target adapter concrete, and assume the
template is a creation factory. Subclasses could still override the
preivously-abstract method.
> I just think that if a palette Entry is equipped with a custom
> CreationFactory, that factory should be used not only on Point&Click but
> also on Drag&Drop - to make it consistent.
In theory, a template could be anything, including the color blue, a layout
manager, etc. Some of these scenarios might not require creation factories.
|
|
|
| Re: TemplateTransferDropTargetListener & CombinedTemplateCreationEntry - Problem [message #195482 is a reply to message #195425] |
Sat, 10 September 2005 04:38 |
| Eclipse User |
|
|
|
Randy Hudson wrote:
>> ...
>> Or: the CreationFactory could be carried in the TemplateTransfer just
>> like the template.
>
> So, we could also make the drop target adapter concrete, and assume the
> template is a creation factory. Subclasses could still override the
> preivously-abstract method.
>
>> I just think that if a palette Entry is equipped with a custom
>> CreationFactory, that factory should be used not only on Point&Click but
>> also on Drag&Drop - to make it consistent.
>
> In theory, a template could be anything, including the color blue, a
> layout manager, etc. Some of these scenarios might not require creation
> factories.
Do I get this right, that in future a CreationFactory is just another
ToolProperty?
If this is true (an idea I like btw), then PaletteEntry constructors like
CombinedTemplateCreationEntry that take CreationFactories as parameters
could just set this ToolProperty instead explicitly setting the factory
variable as it is done now. Something like
setToolProperty(ToolProperty.FACTORY, creationFactory) ...
setToolProperty(ToolProperty.TEMPLATE, template) ...
This way all that needs to be transported in a Transfer*Listener would be
the ToolProperty-HashMap.
This would be very flexible I believe. The DropTargetAdapter could be made
concrete and to the outside, the behavioud would not change, since the
factory is only internally converted to a ToolProperty - actually it would
get more consistent.
|
|
|
Powered by
FUDForum. Page generated in 0.03593 seconds
Home