Skip to main content
[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 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

Back to the top