Carregando um documento no OpenOffice usando um programa Python externo

Question

Estou tentando criar um programa python (usando pyUNO ) para fazer algumas alterações em uma planilha de cálculo do OpenOffice.

Eu lancei anteriormente o OpenOffice no modo "aceitar" para poder conectar-me a partir de um programa externo.Aparentemente, deve ser tão fácil quanto:

import uno
# get the uno component context from the PyUNO runtime
localContext = uno.getComponentContext()

# create the UnoUrlResolver
resolver = localContext.ServiceManager.createInstanceWithContext(
                            "com.sun.star.bridge.UnoUrlResolver", localContext)

# connect to the running office
ctx = resolver.resolve("uno:socket,host=localhost,port=2002;"
                       "urp;StarOffice.ComponentContext")
smgr = ctx.ServiceManager

# get the central desktop object
DESKTOP =smgr.createInstanceWithContext("com.sun.star.frame.Desktop", ctx)

#The calling it's not exactly this way, just to simplify the code
DESKTOP.loadComponentFromURL('file.ods') 

Mas eu recebo um AttributeError quando tento acessar loadComponentFromURL.Se eu fizer um dir(DESKTOP), vi apenas os seguintes atributos/métodos:

['ActiveFrame', 'DispatchRecorderSupplier', 'ImplementationId', 'ImplementationName',
'IsPlugged', 'PropertySetInfo', 'SupportedServiceNames', 'SuspendQuickstartVeto', 
'Title', 'Types', 'addEventListener', 'addPropertyChangeListener', 
'addVetoableChangeListener', 'dispose', 'disposing', 'getImplementationId', 
'getImplementationName', 'getPropertySetInfo', 'getPropertyValue', 
'getSupportedServiceNames', 'getTypes', 'handle', 'queryInterface', 
'removeEventListener', 'removePropertyChangeListener', 'removeVetoableChangeListener', 
'setPropertyValue', 'supportsService']

Eu li que há um bug fazendo o mesmo, mas no OpenOffice 3.0 (estou usando o OpenOffice 3.1 em vez do Red Hat5.3).Eu tentei usar a solução alternativa indicada aqui, mas eles não parecem estar funcionando.

Alguma ideia?

Answer 1

Parece que a edição 90701: http://www.openoffice.org/issues/show_bug.cgi?id=90701

Veja também http://piiis.blogspot.com/2008/10/pyuno-broken-in-ooo-30-with-system.html e http://udk.openoffice.org/python/python-bridge.html

Answer 2

Já faz muito tempo que não fiz nada com o PyUNO, mas olhando o código que funcionou da última vez que o executei em 2006, fiz meu documento de carregamento assim:

def urlify(path):
     return uno.systemPathToFileUrl(os.path.realpath(path))

desktop.loadComponentFromURL(
        urlify(tempfilename), "_blank", 0, ())

Seu exemplo é uma versão simplificada e não tenho certeza se você removeu os argumentos extras intencionalmente ou não.

Se loadComponentFromURL não estiver lá, a API mudou ou há algo errado. Li seu código e parece que você está fazendo as mesmas coisas que eu.

Não acredito que dir() dos métodos no objeto desktop seja útil, pois acho que há um __getattr__ método sendo usado para proxy através das solicitações, e todos os métodos que você imprimiu são métodos utilitários usados ​​para o objeto substituto para o com.sun.star.frame.Desktop.

Acho que talvez a falha seja porque não existe um método chamado loadComponentFromURL que tenha exatamente 1 argumento.Talvez fornecer a versão de 4 argumentos resulte na localização e uso do método.Isso poderia ser simplesmente uma incompatibilidade de impedância entre Python e Java, onde Java tem sobrecarga de método de assinatura de chamada.