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
Tom,

It looks like the deserialization is controlled by @MapContent  annotations.  Note that EMF can deserialize any XML, so it doesn't have to be XMI, so either form should work.  Of course namespace qualification helps to identify the model to use...


Tom Schindl wrote: 
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

Back to the top