[Libreoffice] new configmgr access API ...

On Fri, 2012-01-13 at 14:15 +0100, Stephan Bergmann wrote:
> On 01/13/2012 11:23 AM, Michael Meeks wrote:
> >     Oooh ! :-) it looks really rather nice; how efficient is the compiled
> > representation ? hopefully much more so than the big chunks of in-lined
> > UNO-ness that existing code uses :-)
>
> It still uses UNO to access configmgr, but through a simplified 
> interface (new com.sun.star.configuration.{ReadOnly,ReadWrite}Access 
> singletons).  The main benefit (besides shorter client code) is type 
> safety

        Yep - it's pretty awesome - it's also far less verbose than many of the
configmgr access sites I've seen:

officecfg::Office::Common::AsianLayout::CompressCharacterDistance::get(comphelper::getProcessComponentContext());

        vs.

        css::uno::Any aVal = ::comphelper::ConfigurationHelper::readDirectKey(
                                xSMGR,
                                
::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("org.openoffice.Office.Common/")),
                                ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("Misc")),
                                ::rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("MaxOpenDocuments")),
                                ::comphelper::ConfigurationHelper::E_READONLY);
        sal_Int32 nCount;
        aVal >>= nCount;
        etc.

        So really nice - and has no visible operator overload too; I love
it :-)

>  -- neither can there be misspellings in the paths of 
> configuration nodes nor confusion in the values that can be read or 
> written for those nodes.

        Sure - and I imagine there is a really serious error if the key is not
there or we get an exception reading it, that we can un-conditionally
dump something nice out for to the console when we get to it :-)

> UNO *is* the tool to make functionality available to different 
> languages, to extensions, and to scripting facilities.

        Sure - of course. This API, on the other hand, is a C++ syntactic
sugar, so surely we can do things better in our native language
perhaps ? at least I think taking an efficiency hit to allow the
possibility of a later non-C++ configmgr implementation is unlikely to
pay dividends.

        I'd not seen any of this, so I'm just looking for the first time; I
have a number of queries (given that this will/should be used
everywhere).

* reading:
        workdir/unxlngi6.pro/CustomTarget/officecfg/registry/Office/Common.hxx

        I love the:
        namespace officecfg { namespace Office { namespace Common {

        ie. we skipped the org and the OpenOffice - which is cool; good
        to get over the over-namespacing legacy. My question would be -
        do we even need the 'Office' ? ;-) but ... it's prolly fine for
        now.

* optimising
        Did I mention that I love the ability to transparently optimise
        this later as a major feature of this :-)

* string construction:

        struct UseOldExport: public unotools::ConfigurationProperty<UseOldExport, bool> {
            static rtl::OUString path() { return 
rtl::OUString(RTL_CONSTASCII_USTRINGPARAM("/org.openoffice.Office.Common/InternalMSExport/UseOldExport"));
 }

        Since we're going to get a lot of these inserted, it might be
        rather a good plan to split a path() method from a key()
        method so the compiler can share the:
                /org.openoffice.Office.Common/.../
        for all the keys; that makes the call site slightly larger, but
        the resulting binary potentially rather smaller :-)

        it'd of course also be rather nice to keep the strings
        as const char *'s until we get them into some non-inlined code
        hiding that construction stuff inside some
        static ConfigurationWrapper::getPropertyValue(...) type method ?
        That way we get a single string (buffer) construction to build
        the path instead of one per call-site.

* XComponentContext-age ...
            static ConfigurationWrapper const & get(
                com::sun::star::uno::Reference< com::sun::star::uno::XComponentContext >
                    const & context);

        Do we really need to pass this parameter to these methods ?

        We have a single configmr instance, it seems unlikely that we
        really need anything to help us find it surely ? either
        configmgr is there, or the world goes bang :-)

        If we're desparate to have it (it'd be nice to know what for),
        then we could we have a default-to-NULL pointer to a reference 
        there ?


        And that's about it at first glance. Most of these details can be
hammered out later though, so it's mainly the API that's interesting -
so - just the XComponentContext clutter (?).

        Personally, I'd love to see direct linking to configmgr so we don't
need the component context, and also some punch-throughs, so we don't
need the UNO API bits that force us to allocate OUStrings and Any's etc.

        Anyhow - we should clearly create an EasyHack to drive this goodness
all through the code-base, I suspect it's highly susceptible to
wide-spread volunteer effort. Are you happy enough with it yet to do
that ?

        Great work !

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot