oox service mess
Stephan Bergmann
sbergman at redhat.com
Fri May 31 00:16:17 PDT 2013
On 05/30/2013 07:20 PM, Kohei Yoshida wrote:
> On 05/30/2013 12:21 PM, Noel Power wrote:
>>> is erroneously listed in sc/util/scfilt.component but not included in
>>> scfilt_component_getFactory (sc/source/filter/excel/xestream.cxx);
>>> its implementation got initially moved to the scfilt library, but has
>>> since been removed as it was unreferenced.
>>
>> intentional ( at least from me ) I doubt we want to do formula parsing
>> over uno ( I think Kohei would agree )
> Yup. We just need to leave one service for formula parser available for
> extension developers, but for the internal code we should not be using
> the uno formula parser moving forward.
Just to be clear, with "one service" do you mean
(a) "one service declaration in UNOIDL, for which extension developers
can provide implementations, which the ScParserFactoryMap ctor in turn
iterates over" (which would be com.sun.star.sheet.FilterFormulaParser), or
(b) "one service implementation" (which would be the lost
com.sun.star.comp.oox.xls.FormulaParser)?
> And I believe the one we want to keep is made available by
> ScFormulaParserObj under the "com.sun.star.sheet.FormulaParser" service
> name, and this one is not on the list of services that Stephan listed,
> so we are safe here.
Besides the com.sun.star.sheet.FilterFormulaParser UNOIDL (new-style
marker, i.e., no ctor) service declaration there is indeed also a
com.sun.star.sheet.FormulaParser UNOIDL old-style service declaration,
It appears to be a service that is not available at the global service
manager, but rather something that can be obtained from some Calc-local
manager (ScServiceProvider::MakeInstance handing out ScFormulaParserObj
instances under the "com.sun.star.sheet.FormulaParser" key).
Stephan
More information about the LibreOffice
mailing list