Christian Junker wrote: > I noticed the method getScriptProvider() yesterday which is probably the door > to > the XScriptProviderSupplier, however neither of those are listed in the IDL > reference. In other words: This is probably an unofficial interface, thus no > guarantees for its usability.
It's a *new* interface and AFAIK it is not "unofficial", it was just not documented until now. Thanks for pointing us to this. But even with a proper documentation you wouldn't have a "guarantee" for the availability because our rules don't allow us to add mandatory interfaces to already defined services. We either have to add the new interface as an "optional" one (what makes clear that its availability is not guaranteed) or we must derive a new service from the old one where the interface can be mandatory. But this also doesn't make the availability of the interface reliable for you because the documentation of the method from that you received the service only guarantees you that you get an instance of the "old" one, not the derived one. By deriving services just to have extended interface sets we easily could end up with gazillions of services derived from other services that make our documentation less readable. In many cases like the current one (css.document.OfficeDocument service) all instances of the service implement a common set of interfaces that evolves from release to release (because new feature have been created). This could also be described by different versions of the same service (something we don't have now). This wouldn't change a lot for the client code (instead of querying for interfaces or different service names you would need to check the version), but it would make the documentation better, because you can document all the versions together in a common context. Anyway, in all cases (no documentation, derived or versioned services) you need to use queryInterface to get the desired interface and you need to check the return value, because services aren't represented in our API. Our new "super interface" concepts leaves some room for simplifications here, but only for new APIs. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
