[
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
|
But why not making it configurable which i proposed? Would this make
everyone happy?
Tom
Christian Campo schrieb:
> Ed,
>
> I think thats what I said (or meant) that .exsd maybe not .xsd but since
> .xsd exist and is powerful enough for anything that is missing you could
> enhance it do what you want. (i.e. numbers, date etc.)
>
> I am not about this bloat versus non-bloat thing. (or that it helped me
> understand your point)
>
> Yes we are providing yet another binding for XML (quite obvious) and it
> was posted as reply to Oleg who also posted Yet another binding
> proposal. Just as an alternative. I am not saying either one is good or
> bad. But just there are multiple angles to attack this problem that he
> is trying to solve. Our code exists and it works already for all we can
> say.
>
> I am also not sure that we are after this non-bloat thing (whatever that
> means in this context, I think there is code bloat, API bloat and
> probably others). We want to avoid using this DOM like API that is
> called IConfigurationElement using a very simple XML binding.
>
> Of course everything looks like a EMF problem/solution for some but
> thats ok from your angle or Tom's angle. No criticism intended.
>
> christian
>
> Am 30.09.2008 um 12:29 schrieb Ed Merks:
>
>> Christian,
>>
>> A *.exsd isn't a *.xsd. It's very much like a *.xsd, but
>> unfortunately different. Note in particular the lack of any mention
>> of the http://www.w3.org/2001/XMLSchema namespace. So it's yet
>> another modeling language...
>>
>> Also, it seems what you're providing is yet another XML binding
>> framework for this modeling language. It's definitely interesting and
>> useful, but it's yet another one.
>>
>> I know all these things are done to avoid bloat, but it should be
>> clear that n groups each avoiding bloat end up creating n solutions
>> each of which combine to cause bloat. It's also interesting that the
>> binding is injected by the client rather than supplied by the
>> extension point provider, but that seems like yet another way to cause
>> bloat as each client provides their own binding...
>>
>> Please don't take this as criticism of the design nor the ideas. It's
>> definitely interesting, flexible, and useful compared to manipulating
>> IConfigurationElement, which is yet another DOM API intended to avoid
>> the bloat of using DOM directly...
>>
>>
>>
>> Christian Campo wrote:
>>> 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
>> _______________________________________________
>> 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
