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: [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 >>>> >>>> >>>> -- >>>> 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 >> _______________________________________________ >> 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 -- 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
