|
| Re: TemplateTransferDropTargetListener & CombinedTemplateCreationEntry - Problem [message #195265 is a reply to message #195231] |
Fri, 09 September 2005 01:37   |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Can you not just set a CreationFactory *as* the template object? then
getFactory() would just cast the template to a factory.
"Fabian Wolf" <Fabian.Wolf@informatik.uni-ulm.de> wrote in message
news:dfq2hv$ufk$1@news.eclipse.org...
> 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 18: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 08:38 |
 Fabian Wolf
Messages: 96
Registered: July 2009 |
Member |
|
|
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.02434 seconds
] 
Search
Help
Register
Login
Home
