Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] Extension registry evolution - cross-posted from equinox-dev

Hi,

This is no problem. The extension injection can deal with nested/complex structures.
This structure will get mapped to nested Java objects. This is currently not shown in
http://wiki.eclipse.org/Riena_Getting_Started_with_injecting_services_and_extensions
but the line (from the wiki):
 - an interface or an array of interfaces annotated with @ExtensionInterface than the mapping tries to resolve to a nested element or to nested elements.
indicates that there is more. :-)
For your structure you would get something like that injected into your target via an update method (setter injection)

void update(ISashDef[] sashDefs) {
    for ( ISashDef sashDef : sashDefs ) {
       Sash s = sashDef.createSash();
       IStackDef stackDef = sashDef.getStack();
       for ( IViewPartDef viewPartDef : stackDef.getViewParts() ) {
          String label = viewPartDef.getLabel();
          IViewPart viewPart = viewPartDef.createViewPart();
       }
    }
}

Hmm, I think I do not understand your idea. It seems to my that you are talking about the "producer"
of extensions, right? Which uses EMF? Whereas our extension injection is on the "consumer" side of
extensions.
I might be completely wrong, but probably you can explain it.

Stefan

Tom Schindl wrote:
Hi,

Well this is nice if you contribute one object but what to do if you
want to contribute a more complex structure like:

<sash class="my.ASash">
  <stack class="my.AStack">
    <view-part label="View 1" class="my.V1"></view-part>
    <view-part label="View 2" class="my.V1"></view-part>
  </stack>
</sash>

My current idea is still that I want to contribute such a structure
using EMF (a special extension-point so that no-one needs to depend on EMF).

Tom

Christian Campo schrieb:
  
Hi,

I think having IConfigurationElements mapped to actual Java objects is a
very good idea. The Riena project is using that now for roughly 4 month
with an implementation in its codebase that allows to

- create Java objects from Extensions
- define Interfaces for the ExtensionPoint schema
- inject the Java Objects into any object that is interested in its
information (making the using code independant of extensions but simply
dependant on the interface object)
- automatically re-injects the Objects if extensions are added or
removed (by installing uninstalling bundles)
- create java instances for those attributes where the type is java

Riena has defined an API that uses Extensions and OSGi Services in a
very similar way. You can inject Services or Extensions using one API.
We have a short not yet complete description in the
wiki http://wiki.eclipse.org/Riena_Getting_Started_with_injecting_services_and_extensions 
and of course the code is in the latest M4 build of Riena
(http://wiki.eclipse.org/Riena_Getting_started) and we have quite a
number of Testcases to show how injecting Extensions and Services works
using the API.

cheers

christian campo

Am 24.09.2008 um 21:20 schrieb Oleg Besedin:

    
[Cross-posted from the equinox-dev@xxxxxxxxxxx
<mailto:equinox-dev@xxxxxxxxxxx>]

What would you like to see in the extension registry 2010?

If you have an opinion on how the extension registry can be improved,
please visit:

        http://wiki.eclipse.org/Equinox_Extension_Registry_Work

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=248340

and leave your comments!

So far we have identified several potential areas:

- Create typed Java objects instead of forcing you to crawl through
IConfigurationElements  (see
http://wiki.eclipse.org/Equinox_Extension_Registry_Work_Objects for
details)
- Expand ability to programmatically modify extension registry
- Add support for non-singleton bundles

Does this sound like something you'd like to see in Eclipse?

(Please use this mailing list for general discussions and bug / wiki
for more detailed comments.)

Thanks,
Oleg
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
<mailto:eclipse-incubator-e4-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
      
------------------------------------------------------------------------

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
    

  


Back to the top