[Libreoffice-commits] core.git: 2 commits - reportdesign/source svx/source
sbergman at redhat.com
Fri Nov 8 02:09:03 PST 2013
On 11/08/2013 10:09 AM, Lionel Elie Mamane wrote:
> On Fri, Nov 08, 2013 at 08:57:31AM +0100, Stephan Bergmann wrote:
>> Would it not be better here to change
>> OShape::getSupportedServiceNames instead, to also report
> On the face of it, it sounds reasonable.
> I tried to do it with the attached patch.
> However, rpt_component_getFactory in file
> reportdesign/source/core/api/services.cxx wants to use
> I'm not sure for what exactly; but I expect there it wants a static
> function there (no "this" pointer).
> So we are making getSupportedServiceNames and supportsService
> compatible, but we are making getSupportedServiceNames incompatible
> with getSupportedServiceNames_Static.
> What are the consequences of that? Which incompatibility is
> preferable? I don't know. Do you have an opinion on that?
OShape::getSupportedServiceNames_Static is used by the UNO plumbing when
processing a createInstance call on the global service manager, but only
in a very limited way: If reportdesign/util/rpt.component states that
there is an implementation "com.sun.star.comp.report.Shape" of service
"com.sun.star.report.Shape" in Library_rpt, that means that
return a factory object that (besides css.lang.XSingleComponentFactory)
shall implement css.lang.XServiceInfo that duplicates the relevant
information in reportdesign/util/rpt.component (getImplementationName
returns "com.sun.star.comp.report.Shape", getSupportedServiceNames
returns just "com.sun.star.report.Shape", and supportsService(x) is true
iff x is an element of getSupportedServiceNames()).
When that factory object (via the css.lang.XSingleComponentFactory
interface) delivers an object implementing the
"com.sun.star.report.Shape" service, the expected behavior is that that
implementation object's css.lang.XServiceInfo interface behaves the same
as the factory object's one.
However, in the case of OShape, the implementation object claims to
support an additional service compared to the factory (where that
additional service name obviously cannot be used to obtain an instance
of OShape via the global service manager; I didn't dig into the code to
look what this hack in OShape is actually good for).
I think it is better here to strive for consistency between the
implementation object's supportsService and getSupportedServiceNames
methods, than to strive for consistency between the factory and
implementation object's getSupportedServiceNames methods (as full
consistency between the factory and implementation object's
css.lang.XServiceInfo interfaces is apparently impossible anyway, safe
for a potential redesign of OShape that avoids the hack).
More information about the LibreOffice