| I had a brief chat with Tom about his ideas and (correct me if I am wrong Tom), what you want is something that not only maps the IConfigurationElement to a java object that is just a POJO of this metadata but also allow this POJO to be transformed through a custom handler to a high level object.
My idea was more along the line that the line that IConfigurationElement should be mapped to a POJO and you shouldnt define a customer handler on the extension instance base as in the proposal of Tom (further down).
Maybe a good combination of these two is to define the custom handler when you actually read the data when you call the API. like
Inject.extension("core.test.extpoint").expectingExactly(1).into(target).update("configure").useHandler(myHandler).andStart(getContext());
That way you could transform your POJOs to a higher level object but the owner of the extpt decides what handler to use at read time.
Not sure if that would work for you ?
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@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
|
