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

Back to the top