Sopot Cela Messages: 589 Registered: December 2010
If I got this correctly the part B is not getting the event because the contributor (backing POJO) is not instantiated. That is a normal thing as it is lazy loading the part.
As Christoph said you can supply an addon which activates the part-B. You can do a quick show/hide just to create it from the addon and I would not consider it a publisher-receiver link as the publisher is a separate thing from the addon. The addon's job is just to circumvent the lazy loading of the part, not publish events. The publisher (part A) does not know and has no reference to part B so I don't see where the link is.
There are other alternatives as creating the contributions programmatically using contribution factories but it is better to stick to the services.
Out of curiosity why are you not pushing stuff to the IEclipseContext
(e.g. of the perspective, window or even application) and when the part
gets activated the value will get injected, this sounds the correct
solution. Your current approach e.g. does not allow closing and
reopening the view.
IMHO one uses:
* DI if you want to have the values available all time
* Event-System if the information is import for those currently active
but not interesting for those currently not shown/rendered
Am 16.10.12 14:16, schrieb Sopot Cela:
> Fair enough. Providing your own renderer is a good solution also.
I don't think that pushing the data in an eclipse context helps in my situation. The producing part of the information does not know what the receiving part is and what it likes to do with the data. In my situation the receiver may decide that the data is important to the user and it forces its visibility (with partService.activate(...)). I can't wait until the user activates the part manually. So I have a problem if the associated object is not yet created. I can't see what it helps (in my situation) when I push the data in an eclipse context. Pushing it an a context does not create the object.
According to your list, what mechanism I should use, I have a third situation:
* Data that should not be avaibable all the time and is important for parts not visible.