Re: AW: [eclipse-incubator-e4-dev] Extension registry evolution- cross-p

[Christian Campo <christian.campo@xxxxxxxxxxxx>]

Tom,

I am not sure what you are exactly refering too. If it is the  
contenthandler that you put into the extension instance then this  
confuses me even more. What the purpose of the handler. Will it mangle  
the xml ? So does the XML in the extension conform to the .exsd or the  
output of the handler ? In the first case, what does the handler do  
and will the output of the handler conform, in the later case how can  
you write an extension editor if only the output of a handler has to  
conform to the .exsd ?

Maybe you like to elaborate on what you meant and why exhancing .exsd  
in the direction of .xsd feature does not also help.

christian

Am 30.09.2008 um 13:07 schrieb Tom Schindl:

> 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
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev