Hi Tom,
to underline what Stefan wrote, we have a good testcase that is nearly the
structure that you are talking about.
The plugin xml is like this:
<plugin>
<extension id="core.test.extpoint.id6" point="core.test.extpoint">
<test
required="false"
objectType="java.lang.String"
text="test6">
<data info="rmation"/>
<moreData id="more-one" name="Hugo"/>
<moreData id="more-two" name="Hella"/>
</test>
</extension>
</plugin>
The testcase goes like this:
public void
testWithUnknownTypeAndSingleDataAndOneNestedSingleElementAndTwoNestedMultipleElements()
{
printTestName();
addPluginXml(ExtensionInjectorTest.class, "plugin.xml");
addPluginXml(ExtensionInjectorTest.class, "plugin_ext6.xml");
ConfigurableThingSingleData target = new
ConfigurableThingSingleData();
ExtensionInjector injector =
Inject.extension("core.test.extpoint").expectingExactly(1).into(target).update(
"configure").andStart(getContext());
assertNotNull(target.getData());
assertFalse(target.getData().getRequired());
assertFalse(target.getData().isRequired());
assertEquals("test6", target.getData().getText());
assertEquals(String.class,
target.getData().createObjectType().getClass());
IData2 data2 = target.getData().getNews();
assertNotNull(data2);
assertEquals("rmation", data2.getInfo());
IData3[] data3 = target.getData().getMoreData();
assertNotNull(data3);
assertEquals(2, data3.length);
assertEquals("more-one", data3[0].getId());
assertEquals("Hugo", data3[0].getName());
assertEquals("more-two", data3[1].getId());
assertEquals("Hella", data3[1].getName());
removeExtension("core.test.extpoint.id6");
removeExtensionPoint("core.test.extpoint");
injector.stop();
}
IData the structure that gets injected into ConfigurableThingSingleData is used
for many testcases, so it looks a little bloated (for this showcase) but of
course you would only need those fields that are in the plugin.xml.
@ExtensionInterface
public interface IData {
@MapContent
String getValue();
String getText();
@MapName("required")
boolean getRequired();
boolean isRequired();
short getShortNumber();
int getIntegerNumber();
long getLongNumber();
float getFloatNumber();
double getDoubleNumber();
char getDelimCharacter();
byte getJustAByte();
Object createObjectType();
@MapName("data")
IData2 getNews();
IData3[] getMoreData();
Bundle getContributingBundle();
@MapName("objectType")
Class<?> getLazyThingType();
@CreateLazy()
@MapName("objectType")
ILazyThing createLazyThing();
}
A already running testcase in our Riena CVS with many more examples for
different scenarios of extensions. We make use of this feature within Riena
ourselves (aka "eat your own dogfood") so we came accross already quit some
different types of extensions that we needed to consume.
regards
christian campo
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] im Auftrag von Tom Schindl
Gesendet: Di 30.09.2008 10:06
An: E4 developer list
Betreff: Re: [eclipse-incubator-e4-dev] Extension registry evolution-
cross-posted from equinox-dev
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 [EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>]
>>
>> 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
>> [email protected]
>> <mailto:[email protected]>
>> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________
eclipse-incubator-e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
