XResourceBundle/Loader

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

XResourceBundle/Loader

frank.schoenheit
Hi,

currently, no way exists fore mere UNO components to access localized
resources, i.e. data stored in OOo's *.res files [1]. That's Bad (TM),
since it forces UNO components to use unlocalized error messages, for
instance.

In theory, we have an API for loading resources:
css.resource.XResourceBundle/Loader [2]. Sadly, the bundle and thus
effectively the loader is deprecated. Not to mention that no
implementation exists for those interfaces.

Furthermore, the definition of the bundle seems to be, ehm, heavily
inspired from the respective Java API [3]. This is not bad in itself,
but it at least implies a resource file naming scheme which is not
conform to the resource file naming scheme used elsewhere in the
application.


I'd like to (at least initiate to :) resurrect the resource API, and
here are the items I'd like to discuss:

- Is anybody aware of an existing implementation of this API?

- 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?
  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?

  - 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?

- Is the naming convention issue really an issue? Can we "re-document"
  XResourceBundle to follow OOo's resource file naming conventions, 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)?

- Is there any volunteer for implementing a XResourceBundle/Loader
  components? :)

Thanks for any opinions

Ciao
Frank

[1]No, please don't mention VclStringResourceLoader, which is only
   usable in language bindings like Basic and Python, and has a really
   crude syntax in all other bindings.

[2]http://api.openoffice.org/docs/common/ref/com/sun/star/resource/module-ix.html

[3]http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

Jörg Barfurth
Hi,

Frank Schönheit wrote:

> currently, no way exists fore mere UNO components to access localized
> resources, i.e. data stored in OOo's *.res files [1]. That's Bad (TM),
> since it forces UNO components to use unlocalized error messages, for
> instance.
>

I'm not sure OOo's res files are the best thing to use for components.
At least they seem better suited to strictly office components, than for
any other component that can run in a URE.

FWIW the configuration database can automatically retrieve data for the
current UI locale. This has been (ab)used by component authors to
provide localized messages. I can't say whether we consider that a good
thing, but as one data point, even the OOo command names (for menus or
toolbar tooltips) are localized this way now.

For standalone UNO components the configuration has the added benefit
that configuration files can be deployed using the UNO package manager.

-- Joerg


--
Joerg Barfurth           phone: +49 40 23646662 / x66662
Software Engineer        mailto:[hidden email]
Desktop Technology       http://reserv.ireland/twiki/bin/view/Argus/
Thin Client Software     http://www.sun.com/software/sunray/
Sun Microsystems GmbH    http://www.sun.com/software/javadesktopsystem/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

Juergen Schmidt-3
In reply to this post by frank.schoenheit
Joerg Barfurth wrote:

> Hi,
>
> Frank Schönheit wrote:
>
>> currently, no way exists fore mere UNO components to access localized
>> resources, i.e. data stored in OOo's *.res files [1]. That's Bad (TM),
>> since it forces UNO components to use unlocalized error messages, for
>> instance.
>>
>
> I'm not sure OOo's res files are the best thing to use for components.
> At least they seem better suited to strictly office components, than for
> any other component that can run in a URE.
Exactly my opinion and i hope that we can answer this question in the
context of the general toolkit question. If we will go forward for
example with a XUL approach for UI components we should use the XUL
resource system.

>
> FWIW the configuration database can automatically retrieve data for the
> current UI locale. This has been (ab)used by component authors to
> provide localized messages. I can't say whether we consider that a good
> thing, but as one data point, even the OOo command names (for menus or
> toolbar tooltips) are localized this way now.

I would say it is perfect for components where the UI is done by a
generic approach intern like menu items or toolbars for Add-Ons or in
the future localized display names and descriptions for Calc Add-In
functions. But probably not for complete dialogs.

Juergen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

frank.schoenheit
In reply to this post by Jörg Barfurth
Hi Joerg,

> I'm not sure OOo's res files are the best thing to use for components.
> At least they seem better suited to strictly office components, than for
> any other component that can run in a URE.

Yes, one question I forgot to add to my list is "should the fact that
.res files cannot be created with the SDK hinder us from providing an
UNO API for accessing those files?" :)

Sadly, there's no clear distinction between "URE components" and "strict
office components".
Basically, every component which is above the SDK (means it uses at
least, say, unotools or comphelper or so), but below tools (means, it
cannot access the C++ facilities for resource access) is in some gray
area ...

Exactly this kind of components bothers me currently. I need to provide
our database drivers with localized error messages, but they're not
linked against tools (and this is a Good Thing (TM)).

> FWIW the configuration database can automatically retrieve data for the
> current UI locale. This has been (ab)used by component authors to
> provide localized messages. I can't say whether we consider that a good
> thing, but as one data point, even the OOo command names (for menus or
> toolbar tooltips) are localized this way now.

Well, I consider this a hack ;)

For toolbars/menus, this might be a valid approach since in this case,
we're perhaps really talking about "configuration data". For our
database drivers, I don't consider the error messages to be
"configuration data", and thus storing them in the configuration a clear
abuse.

> For standalone UNO components the configuration has the added benefit
> that configuration files can be deployed using the UNO package manager.

The fact that the UNO package manager cannot deploy any other resource
files than configuration files is a deficiency of the UNO package
manager. It should not be an argument for abusing the configuration for
component localization.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

frank.schoenheit
In reply to this post by Juergen Schmidt-3
Hi Jürgen,

> Exactly my opinion and i hope that we can answer this question in the
> context of the general toolkit question. If we will go forward for
> example with a XUL approach for UI components we should use the XUL
> resource system.

I was more looking for a solution which can be used within the next few
months ... ;)

> I would say it is perfect for components where the UI is done by a
> generic approach intern like menu items or toolbars for Add-Ons or in
> the future localized display names and descriptions for Calc Add-In
> functions. But probably not for complete dialogs.

Admittedly, I'm currently only looking for localized strings, not for a
UNO API for *all* the functionality of our C++ resource system. However,
still I'd consider storing those strings in the configuration a hack
(see the other mail).

Given that in Java, as well as in XUL, localizing of strings is often
done via properties files, would it be reasonable to add support for
properties files (basically text files with a list of name=value pairs)
to OOo, and create an UNO API for it? This should be future-proof: No
matter which other toolkit we'll use later on, chances are good that it
will also (need to) support such kind of localized strings.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

Juergen Schmidt-3
In reply to this post by frank.schoenheit
Frank Schönheit - Sun Microsystems Germany wrote:

> Hi Jürgen,
>
>> Exactly my opinion and i hope that we can answer this question in the
>> context of the general toolkit question. If we will go forward for
>> example with a XUL approach for UI components we should use the XUL
>> resource system.
>
> I was more looking for a solution which can be used within the next few
> months ... ;)
>
>> I would say it is perfect for components where the UI is done by a
>> generic approach intern like menu items or toolbars for Add-Ons or in
>> the future localized display names and descriptions for Calc Add-In
>> functions. But probably not for complete dialogs.
>
> Admittedly, I'm currently only looking for localized strings, not for a
> UNO API for *all* the functionality of our C++ resource system. However,
> still I'd consider storing those strings in the configuration a hack
> (see the other mail).
>
> Given that in Java, as well as in XUL, localizing of strings is often
> done via properties files, would it be reasonable to add support for
> properties files (basically text files with a list of name=value pairs)
> to OOo, and create an UNO API for it? This should be future-proof: No
> matter which other toolkit we'll use later on, chances are good that it
> will also (need to) support such kind of localized strings.
Having the overall picture (where we want to go in the future) in mind
can help to find the right solution for your localized strings now. I
agree that property files maybe can help here.

Juergen

>
> Ciao
> Frank
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

Eike Rathke
In reply to this post by frank.schoenheit
Hi Frank,

On Tue, Mar 14, 2006 at 13:09:29 +0100, Frank Schönheit wrote:

> In theory, we have an API for loading resources:
> css.resource.XResourceBundle/Loader [2]. Sadly, the bundle and thus
> effectively the loader is deprecated. Not to mention that no
> implementation exists for those interfaces.
>
> - Is anybody aware of an existing implementation of this API?

AFAIR Dirk Voelzke had a "private" implementation of it, or something
alike.


> - 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


>   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.


>   - 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..


> - 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.

>   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?

> - Is there any volunteer for implementing a XResourceBundle/Loader
>   components? :)

Go ahead ;-)

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 GnuPG key 0x293C05FD:  997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

frank.schoenheit
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         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

frank.schoenheit
In reply to this post by Juergen Schmidt-3
Hi Jürgen,

> Having the overall picture (where we want to go in the future) in mind
> can help to find the right solution for your localized strings now.

Who does have this picture, and when?

> I agree that property files maybe can help here.

Reading Eike, who also has the requirement to access strings in existing
resources ....

Maybe we can define a "service OfficeResourceBundleLoader :
XResourceBundleLoader", which explicitly states that it is able to load
resources from OOo resource files. This way, we would not pollute the
basic interfaces.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         [hidden email] -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Database                   http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: XResourceBundle/Loader

Juergen Schmidt-3
In reply to this post by frank.schoenheit
Frank Schönheit wrote:
> Hi Jürgen,
>
>> Having the overall picture (where we want to go in the future) in mind
>> can help to find the right solution for your localized strings now.
>
> Who does have this picture, and when?

good question, i would say we have put the brushes and colors on the
table to start drawing ;-)
No, i think that we have some ideas. From my point of view the most
promising thing is the XUL approach for components first and maybe later
for other parts of the office also. And the second promising way is the
extension or redesign of the existing awt toolkit. But of course no
decision is made so far.

>
>> I agree that property files maybe can help here.
>
> Reading Eike, who also has the requirement to access strings in existing
> resources ....
>
> Maybe we can define a "service OfficeResourceBundleLoader :
> XResourceBundleLoader", which explicitly states that it is able to load
> resources from OOo resource files. This way, we would not pollute the
> basic interfaces.

good idea to solve the current problem and to provide a fast solution
for now. But nobody should expect that we will enable the deployment of
this resource files at this time, i won't make it public for components
until the question of a toolkit and a related resource format is answered.

Juergen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]