Bug 88815 - simplify service declarations
Summary: simplify service declarations
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyMedium, easyHack, skillCpp, topicCleanup
Depends on:
Blocks: Dev-related
  Show dependency treegraph
 
Reported: 2015-01-26 21:47 UTC by Michael Meeks
Modified: 2023-05-10 09:03 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2015-01-26 21:47:37 UTC
If you do a:

$ git grep -5 of getImplementationName

you can see a truck-load of duplicated code :-) doing the most banal of things.

It might be nice to have a macro that we can replace both the methods of:

XServiceInfo

with - and (I guess) also provide a stock 'static' version of the same - that returns the service name.

Occasionally an implementation provides a couple or more serviecs, so some var-arg-ness to that might be rather useful:

Perhaps include/cppuhelper/supporsservice.hxx would be a good place for that macro to live.

Thanks !
Comment 1 Stephan Bergmann 2015-01-27 08:52:01 UTC
there is already include/comphelper/servicedecl.hxx implementing that
Comment 2 Michael Meeks 2015-01-27 10:19:49 UTC
Ah - nice =) so unfortunately even I find the template code extremely hard to follow; but I guess we need to replace:

    virtual OUString SAL_CALL getImplementationName()
        throw (css::uno::RuntimeException) SAL_OVERRIDE;
    virtual sal_Bool SAL_CALL supportsService( OUString const& name )
        throw (css::uno::RuntimeException) SAL_OVERRIDE;
    virtual css::uno::Sequence< OUString>
    SAL_CALL getSupportedServiceNames() throw (css::uno::RuntimeException) SAL_OVERRIDE;

and their implementations with:

#include <comphelper/servicedecl.hxx>

and a class member thus:

    comphelper::service_decl::ServiceDecl const myDecl(
        sdecl::class_<MyClass>(),
        "com.sun.star.comp.my.unique.implementation.name",
        "com.sun.star.draw.MyServiceSpec1;com.sun.star.draw.MyServiceSpec2" );

Is it truly the case that that can be done without altering the inheritance hierarchy of the implementor ? ie. we still use WeakImplBase3<XServiceInfo,...> or somesuch ?
Comment 3 Björn Michaelsen 2015-03-03 00:29:02 UTC
> Is it truly the case that that can be done without altering the inheritance
> hierarchy of the implementor ? ie. we still use
> WeakImplBase3<XServiceInfo,...> or somesuch ?

You dont even need the XServiceInfo in the WeakImplBase template. see e.g. 
::extensions::resource::OpenOfficeResourceLoader for something small without constructor arguments and ::extensions::resource::ResourceIndexAccess for something with them. The servicedecl magic for them is in extensions/source/resource/resourceservices.cxx.
Comment 4 Robinson Tryon (qubit) 2015-12-10 11:41:09 UTC Comment hidden (obsolete)
Comment 5 Robinson Tryon (qubit) 2016-02-18 14:51:31 UTC Comment hidden (obsolete)
Comment 6 JoNi 2016-12-16 11:28:03 UTC
few questions about this task:

does the ServiceDecl template work with classes who don't have ctors like:
> MyClass( uno::Sequence<uno::Any> const& args,
>          uno::Reference<uno:XComponentContext> const& xContext )
> MyClass( uno::Reference<uno:XComponentContext> const& xContext )
if yes, what do I have to consider to make it work?


all ServiceDecl objects are defined locally and used in some xxx_component_getFactory() what is this about?


I think one *must* remove XServiceInfo from the class to use ServiceDelc, but what about classes who inherit XServiceInfo via UnoAPI (in *.idl). Like chart2/source/model/inc/Diagram.hxx who inherits it from XDiagram (and WeakImplHelper macro).