Difference between revisions of "Helperapi"
From Apache OpenOffice Wiki
(→How is it different from oovbaapi) |
B michaelsen (Talk | contribs) |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | As you may have read Sun has kindly donated it's compatibility [http://api.openoffice.org/source/browse/api/helperapi/ helperapi] that was part of the macro migration toolkit. | + | As you may have [http://blogs.sun.com/GullFOSS/entry/sun_and_novell_work_together read] Sun has kindly donated it's compatibility [http://api.openoffice.org/source/browse/api/helperapi/ helperapi] that was part of the macro migration toolkit. |
=== How is it different from oovbaapi === | === How is it different from oovbaapi === | ||
| Line 8: | Line 8: | ||
=== Why ditch the helperapi and use the oovbaapi from ooo-build written in C++ === | === Why ditch the helperapi and use the oovbaapi from ooo-build written in C++ === | ||
| − | * hard to track memory and performance problems across language and bridge boundaries | + | * with a java uno component implementation it's hard to track memory and performance problems across language and bridge boundaries |
| − | * the existing uno api ( e.g. for calc and writer ) does not provide enough functionality. | + | * in many instances the existing openoffice uno api ( e.g. for calc and writer ) does not provide enough easily leveraged functionality to efficiently ( and quickly ) build a compatibility api from. |
| − | * The existing applications ( calc & writer ) and the basic runtime are written in C++ and as such its easier to interact at a lower level using c++. The alternative is to expose the bits need via uno, that itself is not a trivial task. | + | * The existing applications ( calc & writer ) and the basic runtime are written in C++ and as such its easier to interact at a lower level using c++. The alternative is to expose the bits need via uno, that itself is not a trivial task. |
=== How is it structured === | === How is it structured === | ||
| Line 27: | Line 27: | ||
## a nice test harness infrastructure is necessary to help track progress, highlight known errors and indicate any regressions. The test documents which are both word and excel documents already include a test framework for logging the test results in log files. Whats missing is the infrastructure to run these tests automatically and compare the test results and a 'known' expected result. | ## a nice test harness infrastructure is necessary to help track progress, highlight known errors and indicate any regressions. The test documents which are both word and excel documents already include a test framework for logging the test results in log files. Whats missing is the infrastructure to run these tests automatically and compare the test results and a 'known' expected result. | ||
# a similar base class to [http://api.openoffice.org/source/browse/*checkout*/api/helperapi/impl/com/sun/star/helper/HelperInterfaceAdaptor.java?rev=1.1 HelperInterfaceAdaptor] | # a similar base class to [http://api.openoffice.org/source/browse/*checkout*/api/helperapi/impl/com/sun/star/helper/HelperInterfaceAdaptor.java?rev=1.1 HelperInterfaceAdaptor] | ||
| + | [[Category:VBA]] | ||
Latest revision as of 18:26, 9 March 2010
As you may have read Sun has kindly donated it's compatibility helperapi that was part of the macro migration toolkit.
Contents
How is it different from oovbaapi
- written in Java
- supports both word and excel
- has a nice set of test documents
- each uno object in the helperapi is a service ( and has a service definition )
Why ditch the helperapi and use the oovbaapi from ooo-build written in C++
- with a java uno component implementation it's hard to track memory and performance problems across language and bridge boundaries
- in many instances the existing openoffice uno api ( e.g. for calc and writer ) does not provide enough easily leveraged functionality to efficiently ( and quickly ) build a compatibility api from.
- The existing applications ( calc & writer ) and the basic runtime are written in C++ and as such its easier to interact at a lower level using c++. The alternative is to expose the bits need via uno, that itself is not a trivial task.
How is it structured
Useful directories
- basic provides some global functions written in basic to bootstrap the api
- com idl subsytem
- impl java implementation
- test_documents a set of documents ( excel and word )
- util/constants generated building of uno constants
What pieces are worth porting?
- the auto generation of the constants type library
- constants are autogenerated form the *.api files located in the util/ms_api directory
- the object implementations themselves. see the porting example and the porting notes
- the testdocuments
- a nice test harness infrastructure is necessary to help track progress, highlight known errors and indicate any regressions. The test documents which are both word and excel documents already include a test framework for logging the test results in log files. Whats missing is the infrastructure to run these tests automatically and compare the test results and a 'known' expected result.
- a similar base class to HelperInterfaceAdaptor
