Hey Daniel, On Fri, 2008-08-29 at 09:29 +0200, Daniel Rentz wrote: > Hi Kohei > > > some thoughts about the new ExternalDocLinks API in CWS mooxlsc... > > First, there is no documentation in the IDL files, please consider to > add some ;-)
Well, real men use code as the documentation. ;-) On a serious note, I will add documentation as soon as the API is finalized. I didn't because A) I ran out of time last night (it was 1:10 am in my time), and B) I was expecting you to comment on it for further change as soon as I checked in my first version, and you did. :-) > I think, a cleaner way to implement the service ExternalDocLinks is to > make it a container, i.e. to support the interfaces XNameAccess, > XIndexAccess, and XEnumerationAccess, similar to e.g. the DDELinks > service. The interface XExternalDocLinks would add the new method > addDocLink() that looks for an existing link or creates a new one, and > returns the index. The XNameAccess uses the URLs as names. Ok. > > The elements of the container could implement the new service > ExternalDocLink which is a container too. Elements are the > ExternalSheetCache objects, names of the elements are the sheet names in > the external document. A new interface XExternalDocLink adds the method > addSheetCache() that looks for an existing cache similar to above. That was in fact pretty much my first version, then I realized that it was not consistent with the internal API from ScExternalRefManager, so I simplified it by removing the container class. But I can add it back for consistency's sake with the DDELink API. It just will be mostly a glue code though since internally there is no doc link container for each linked document. > To do: do we need API to remove something from the cache, or an entire > cache, or even an entire external linked document? I think we do, eventually. I would like to eventually export much of ScExternalRefManager's functionality via API so that we could use it for export filters as well as automation. But I'm still on my first version, so not all of its functionality is made available yet. (And this implies that the interfaces will not be published as of yet.) > Yes I know, that would be a little bit more work, but would make the new > API more consistent to the existing Calc API. :-) Well, I'm all for API's consistency. But keep in mind that I'm not through with my API yet. I checked it in so that we can start our discussion on API design (like this one). :-) Thanks for your comment, Daniel. Kohei -- Kohei Yoshida - OpenOffice.org Engineer - Novell, Inc. <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
