[Libreoffice-commits] core.git: 2 commits - reportdesign/source svx/source

[Stephan Bergmann]

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
>> m_sServiceName?
>
> 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
> OShape::getSupportedServiceNames_Static
>
> 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 
rpt_component_getFactory("com.sun.star.comp.report.Shape",...) shall 
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).

Stephan