On 06/06/2012 01:43 PM, Tor Lillqvist wrote:
Now I am having second thoughts, though, but still, a first, in
progress, draft API is in UNOIDL form is in touch/idl.
I see no need for a DocumentRenderCallback service.
XDocumentRenderCallback will be implemented by UNO objects specific to
the various callers of XDocument.render; there is no reasonable generic
implementation that could be offered as a service. (Also, there is a
subtle difference between an explicit zero-parameter constructor and an
implicit default constructor for UNO services, relating to whether the
constructor internally calls createInstanceWithContext or
createInstanceWithArgumentsAndContext.)
But, that's the *specification* and *use*. *Implementing* UNO services
in C++, especially if you don't want to just copy-paste existing code
as a start, and then modify, without understanding what the parts you
don't touch is exactly doing, is still nightmarish with loads of
boilerplate-ish rubbish.
I would go the UNO approach nevertheless. If you want to be able to
call this from Java, don't underestimate the work you save by reusing
UNO here. Your impression might vary, but I would say this vastly
compensates for the mild amount of boilerplate you need on the C++
implementation side. (I might of course be routine-blinded, but in my
eyes the necessary boilerplate boils down to not that much really.)
Stephan
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.