I am planning to write openoffice macros using openoffice basic language. I am struggling to find the objects and methods related to openoffice documents. I googled and found some example codes and the API page openoffice.org/api but I could not locate where are the objects and methods in the api.
For example read this line of code
oSheet=oDoc.Sheets.getByName("Sheet1")
There is no method/object in the name "sheets", getByName when i referred the API page (openoffice.org/api). Where should I look for?
Short answer:
Sheets can be obtained by name, index or enumeration through the interface com.sun.star.sheet.XSpreadsheetDocument.
oSheets = oDoc.getSheets().getByIndex(0)
Explanation:
Then what is oDoc.Sheets?
To really understand the UNO API, it's best to use Java. Here is some code that you don't need to read, but I show it here because the results will be helpful.
XSpreadsheetDocument xSpreadSheetDocument = UnoRuntime.queryInterface(
XSpreadsheetDocument.class, xComponent);
XSpreadsheets xSpreadsheets = xSpreadSheetDocument.getSheets();
XPropertySet propSet = (XPropertySet)UnoRuntime.queryInterface(
XPropertySet.class, xComponent);
Using code like this, we can verify that getSheets() works in Java, but Sheets() does not. Nor is there any property named Sheets in the property set. In short, there is no Sheets in Java, so Sheets must not be part of the UNO API.
Now, languages that are less strict than Java, such as Basic and Python, have various shortcuts to work with UNO. For one thing, they do not need queryInterface to get a specific object, because they don't care about the type.
Another shortcut is that they provide properties that can be used as alternatives to the method of a particular interface. So, the method XSpreadsheetDocument.getSheets() gets a shortcut property Sheets. Similarly, the method XDocumentSupplier.getDocumentProperties() gets a shortcut property DocumentProperties. Both of these properties are members of oDoc when writing in Basic or Python.
Finding Information:
Searching through the API documentation is not easy. Before trying that, it's better to search for example code. Andrew Pitonyak's macro document contains a set of examples that cover many needs, and searching in Google will bring up example code from sites such as ask.libreoffice.org.
Also, an introspection tool such as XrayTool or MRI is essential. Such tools give a list of all properties and methods available for an object, and since the list is flat, there is less need to dig into the interface of an inherited interface of another interface and so on.
Related
I'm trying to understand what is an FP-alternative to good old dependency injection from OOP.
Say I have the following app (pseudocode)
app() is where application starts. It allows user to register and list user posts (whatever). These two functions are composed out of several other functions (register does it step by step, imperatively, while list posts really composes them (at least this is how I understand function composition).
app()
registerUser(u)
validate(u)
persist(u)
callSaveToDB(u)
notify(u)
sendsEmail
listPosts(u)
postsToView(loadUserPosts(findUser(u)))
Now I'd like to test this stuff (registerUser and listPosts) and would like to have stubbed functions so that I don't call db etc - you know, usual testing stuff.
I know it's possible to pass functions to functions e.g
registerUser(validateFn, persistFn, notifyFn, u)
and have it partially applied so it looks like registerUser(u) with other functions closed over and so on. But it all needs to be done on app boot level as it was in OOP (wiring dependencies and bootstraping an app). It looks like manually doing this will take ages and tons of boilerplate code. Is there something obvious I'm missing there? Is there any other way of doing that?
EDIT:
I see having IO there is not a good example. So what if I have function composed of several other functions and one of them is really heavy (in terms of computations) and I'd like to swap it?
Simply - I'm looking for FP way of doing DI stuff.
The way to answer this is to drop the phrase "dependency injection" and think about it more fundamentally. Write down interfaces as types for each component. Implement functions that have those types. Replace them as needed. There's no magic, and language features like type classes make it easy for the compiler to ensure you can substitute methods in an interface.
The previous Haskell-specific answer, shows how to use Haskell types for the API: https://stackoverflow.com/a/14329487/83805
In declaration of class "DeclarationMirror" I found these documentation about the "owner" property.
For a `parameter`, `local variable` or `local function` the owner is
the immediately enclosing function.
I cannot understand how interpret this information because I cannot find documentation about how to reflect the following declarations through Dart mirrors library.
Local variable
Local function
How should I interpret these terms applied to practical usage of this library?
Notice about the declarations that must be necessarily implemented in future but, for several reasons, currently not implemented.
Information unreliable and can not be perceived as documentation.
I more interested in item #1.
If this is a real documentation but not a unreliable information then where I can find information on which based these documentation?
That is, where is information about described in documentation local variables and local functions mirrored declarations?
I am about how to reflect them from their owners.
I hope that I quite correctly asked question about the official documentation, given its purpose.
If there exist another way to describe this I'll be glad to hear it.
P.S.
This question asked on that reason that there is no other available information found in official documentation.
P.S.
Sample of code:
var clazz = reflectClass(MyClass);
var method = clazz.declarations[#myMethod];
// How to reflect mentioned in documentation local variable?
var localVariable = method.declarations[#myLocalVariable];
The sample of code is just an example, but official documentation is more similar to the law. It must clearly be interpreted.
As I see this:
The immediately enclosing function is indeed the owner of the local variables and local functions.
But that doesn't include that you can get hold of them by reflection.
I tried to assign a local function to a field of the class and tried then to get hold of the function using reflection. I got the field but don't know how to get the value the field references to (the local func)
Maybe this is possible but I couldn't find how.
If this would work the owner would probably be the enclosing function.
AFAIR there was a discussion somewhere that it is currently not possible to access local members using reflection but I'm not very sure about this.
I also think I saw somewhere that you can get the source of a function as text if that is of any use...
I'm trying to find an interface which allows me to create a stream which allows seeking (just a Reader is fine, too) from either a file or []byte, but can't seem to find anything in the godoc. Some of the types in the bufio package would work quite well, but they don't appear to support seeking.
Is there something I overlooked which would fit what I'm looking for?
Both *os.File (for files) and *bytes.Reader (for having an io.Reader from a []byte) implement the io.Seeker interface and thus have a Seek method.
io.Seeker is implemented by...
*bytes.Reader
*io.SectionReader
io.ReadSeeker
io.WriteSeeker
io.ReadWriteSeeker
mime/multipart.File
net/http.File
*os.File
*strings.Reader
So if you're working with a file, thus very likely *os.File, you don't need to do anything additional to be able to seek it. Just make sure that if you're using interfaces instead of concrete types that you do not want an io.Reader but an io.ReadSeeker.
For instance I have this bit of code
public class ProductService{
private IProductDataSource _dataSource = DependencyManager.Get<IProductDataSource>();
public Product Get(int id){
return _dataSource.Select(id);
}
}
I have 2 different data source:
XML file which contains the informations only in 1 language,
a SQL data base which contains the informations in many languages.
So I created 2 implementation for IProductDataSource, for for each kind of datasource.
But how do I send the required language to the SQL data source ?
I add the parameter "language" to the method "IProductDataSource.Select" even if I won't use it in the case of the XML implementation.
Inside the SQL implementation I get the language from a global state ?
I add the language to the constructor of my SQL implementation, but then I won't use my DependencyManager and handle my self the dependency injection.
Maybe my first solution is not good.
The third option is the way to go. Inject the language configuration to your SQL implementation. Also get rid of your DependencyManager ServiceLocator and use constructor injection instead.
If your application needs to work with multiple languages in a single instance I think point one is a sensible approach. If the underlying data does not provide translations for a request language then return null. There is another solution in this scenario. I'm assuming that what you have is a list of products and language translations for each product. Can you refactor your model so that you do not need to specify or asertain the langauge until you reference language specific text? The point being a product is a product regardless of the language you choose to describe it. i.e. one product instance per product, only the product id on the Datasource.Select(..) method and some other abstraction mechanism to deal with accessing the correct text translation.
If however each instance of your application is only concerned with one language set I second Mr Gloor.
First of all I need to point out that you are NOT injecting any dependencies with your example - you are depending on a service locator (DependencyManager) to get them for you. Dependency injection, simply put, is when your classes are unaware of who provides the dependencies, e.g. using a constructor, a setter, a method. As it was already mentioned in the other answers, Service locator is an anti-pattern and should be avoided. The reasons are described in this great article.
Another thing is that the settings you are mentioning, such as language or currency, seem to be localization related and would probably be better dealt with using the built-in mechanisms of your language of choice (e.g. resource files, etc).
Now, having said that, depending on how the rest of your code is structured you have several options to solve this while still using Service locator:
You could have SqlDataSource depend on some ILanguageProvider which pulls the current language from somewhere. However, with more settings like these (or if it is difficult to get current language in an isolated way) this can get messy very fast.
You could depend on IProductDataSourceFactory instead (or, if you are using C#, Func<IProductDataSource>) which would return the concrete implementation with the correct settings. Again, you need to be able to get the current language in an isolated way in order to use this.
You could go with option 1 in your question. This would be a leaky abstraction but would be the simplest to implement.
However, if you decide to get rid of service locator and start using some DI container, the best solution would be using option 3 (as it was already stated) and configuring container accordingly to provide the correct value. Some good ideas of how to do this in an elegant way can be found in the answer to this question
I have a typelib that describes some interfaces. As some of these interfaces are used as a category, I want to add the category IDs to the typelib. So the question is:
a) how can this be done in Delphi (2007 and up)?
or as an alternative
b) is it possible and advisable to use the interface GUID for the CATID?
For a), I don't know Delphi. But in C++ it's simply adding the interface description to the MIDL file. As you seem to really only use the interface, you probably do not need a CoClass implementation either, so this would suffice already. Basically, how did you add the other interfaces to the typelib? Do it the same way now.
[edit]I've found a short tutorial on using the typelib-editor. Seems that adding interfaces is only a matter of the correct keyword.[/edit]
As for b), I do not see any problem to use interfaces as a category-id, but this question is a bit vague... As the set of possible categories is fixed, and you do not use some inheritance like behavior (at least I think so as you said you use the interface GUID, not the interface itself), why not just use an enumerator? Using interfaces etc. seems like an over-engineered solution, except if the interfaces are really used as such, i.e. providing access to some category-specific behavior.
[edit]As you're talking about ICatRegister et al., I see why you want to use GUIDs. As the category GUIDs are in a different namespace than the COM interface GUIDs, sure, use the same. Your interface GUIDs need to be unique within the same scope as the category-ids anyhow, and having a 1:1 mapping seems a simple model for maintenance, too.[/edit]