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 <[EMAIL PROTECTED]>* > Sent by: [EMAIL PROTECTED] > > 09/30/2008 03:51 AM > Please respond to > E4 developer list <[email protected]> > > > > To > E4 developer list <[email protected]> > 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 [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>] > > 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_ > [EMAIL PROTECTED] > <mailto:[email protected]> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > > > ------------------------------------------------------------------------ > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > 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 [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
