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