[
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
|
Well its more or less XSD but not full support e.g. you can't say the
attribute is only a number, ... . Why should I hand craft may own editor
if anything I need already available.
If I the underlying system allows me to replace/configure the
deserialization engine I'm already happy.
something like this:
<extension id="core.test.extpoint.id6" point="core.test.extpoint"
contentHandler="org.eclipse.emf.Handler">
<xmi:test
required="false"
objectType="java.lang.String"
text="test6">
<xmi:data info="rmation"/>
<moreData id="more-one" name="Hugo"/>
<moreData id="more-two" name="Hella"/>
</xmi:test>
</extension>
vs.
<extension id="core.test.extpoint.id6" point="core.test.extpoint"
contentHandler="org.eclipse.emf.RienaHandler">
<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>
Maybe are talking about different things, though. Where does the
translation between XML and Java happen. Do I control this or is this
controlled from the internals?
Tom
Christian Campo schrieb:
> Hi Tom,
>
> look at the IData structure below. You find thinks like @MapName which
> maps an attribute with name "x" to certain getter in the interface with
> possibly different name. So that is one way to do customization.
>
> I am not sure I agree we your point on .exsd since it uses XML Schema
> inside. There is already some editor in the PDE and if you look for more
> types or more structure then I guess XSD has enough possibilities and
> its own type system for defining any possible definition that you want
> to put in XML.
>
> So what metadata are you missing that you could not get out of XSD ?
> (but find in XMI)
>
> christian
>
> Am 30.09.2008 um 11:27 schrieb Tom Schindl:
>
>> 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
>> _______________________________________________
>> 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
