[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [eclipse-incubator-e4-dev] Extension registry evolution- cross-posted from equinox-dev
|
Hi Christian,
My main problem with the current extension-point is that the .exsd is
not a real meta data definiton one can use to create a full featured
editor to make creation as easy as possible.
So let me rephrase my question. Is it possible to customize how the
translation from the contributed XML definition is translated into
Java-Objects and if I e.g. know that I contribute an XMI-Fragment I can
directly feed this into emf deserialisation chain.
Tom
Campo, Christian schrieb:
> 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: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx 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 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
>
>
> --
> 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
> 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
--
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
