Hi Eike, >>- Does it make sense to use the css.resource API for accessing OOo >> resources, or are there other problems ahead which suggest we define a >> new API? > > I know of at least one case where being able to access already existing > OOo resources would be of help, which is about obtaining the localized > language/locale names OOo knows, see > http://qa.openoffice.org/issues/show_bug.cgi?id=59738
which means implementing this at the top of properties files would not really be helpful for your issue. (But VclStringResourceLoader would. Though, I continue to think it's a strange hack somebody implemented to solve exactly this kind of problem, and should not really be propagated. Sorry to the author, if s/he's reading here :) >> For instance, execpt the naming convention mentioned above: >> >> - Is it a problem that the css.resource API uses strings as keys to >> resource elements, while OOo's internal resource format is based on >> "resource type / resource id" pairs? > > > I'm not sure how mapping strings to IDs would work without having to > define yet another ugly mapping table. Maybe Dirk can shed some light on > that. Well, at least something like "RID:<numeric_id>" would work ... This could be part of the specification of some OfficeResourceBundle service/interface, so we wouldn't pollute the basic interfaces with it. >> - OOo's internal resource features hierarchic resources, a very >> powerful concept. This would (perhaps) be lost when using the >> existing css.resource API. Would it really? Would it be bearable to >> lose this feature? > > I wonder whether that is actually used anywhere above svx, if at all.. dbaccess has quite some uses. Since I needed to implement some helper classes back in time when I wrote them (svt::OLocalResourceAccess), I suppose nobody else used it so far :) >>- Is the naming convention issue really an issue? Can we "re-document" >> XResourceBundle to follow OOo's resource file naming conventions, > > Since that is a yet unimplemented OOo API I'd say sure, why not. If it's > only the file naming and no type information change it shouldn't be > a problem, even if someone had an own implementation of the interface. Thank's what I think, too. >> or can we simply live with two different conventions (or even, on >> the medium term, move the existing resource files to the Java-like >> convention)? > > I don't think that's worth the effort. Or would it have any other > benefit than just following Java's naming convention? Not really, I think. >>- Is there any volunteer for implementing a XResourceBundle/Loader >> components? :) > > Go ahead ;-) I'd like to :), but since there are objections from our API gatekeeper, I'm not sure ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
