[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] Extension registry evolution - cross-posted from equinox-dev
|
Hi Oleg,
This was my way of thinking to (See other mails in this thread). Can we
somehow make the XML => Java Conversion Plugable so that someone can
provide a converter which uses whatever technology (Betwixt, EMF, ...)
to create the Java-Object-Instances from the XML?
Tom
Oleg Besedin schrieb:
>
> 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
>
> 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@eclipse.org_
> <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@eclipse.org_
> <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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
