Thank you for bringing this up. Riena
definitely has an interesting approach to the extension registry.
It seems that the basic difference is
in how injected objects are created: Riena creates an interface-based object
instantiated as a proxy to the IConfigurationElement. I am thinking about
creating an actual Java object based on the data in the IConfigurationElement.
>From what I see in Riena's code, it builds:
UserClass
[containing UserInterface
[instantiated as
Proxy
[backed
up by IConfigurationElement]]]
I'd rather have:
UserClass <= with data injected at
the time ExtensionRegistry.getObjects() is called
One upside to the "proxy"
approach is that data is lazily populated from the IConfigurationElement
into the UserClass. However, this process should be relatively fast as
the data is already in memory (unless contained elements have expensive
constructors). I'd guess that for simple elements the levels of indirection
added by the proxy likely going to offset performance benefits from the
lazy initialization. Also, the code in the UserClass would have to obtain
data through the UserInterface adding an extra layer.
Are there other advantages to the proxy-based
approach?
Annotations: In my quick search through
the code I was not able to figure out how much Riena’s processing depends
on annotations. It seems that all references to this mechanism use annotations,
but some comments in Javadoc implied that annotations are optional (but
"highly recommended" :-))?
Another interesting difference is that
Riena obtains element types either as arguments (for top-level elements)
or from UserInterface signatures (for child elements). For my proposal,
as it needs to use schema files anyway (can't rely on annotations), I was
thinking about describing types in the schema file.
Thanks,
Oleg
Christian Campo <christian.campo@xxxxxxxxxxxx> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
09/30/2008 03:51 AM
Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
Re: [eclipse-incubator-e4-dev] Extension
registry evolution - cross-posted from
equinox-dev
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
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
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