Difference between revisions of "Helperapi"
From Apache OpenOffice Wiki
B michaelsen (Talk | contribs) |
|||
| (8 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 5: | Line 5: | ||
* supports both word and excel | * supports both word and excel | ||
* has a nice set of test documents | * 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++ === | === 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 === | ||
Useful directories | Useful directories | ||
| − | * | + | * [http://api.openoffice.org/source/browse/api/helperapi/basic basic] provides some global functions written in basic to bootstrap the api |
| − | * | + | * [http://api.openoffice.org/source/browse/api/helperapi/com com] idl subsytem |
| − | * | + | * [http://api.openoffice.org/source/browse/api/helperapi/impl impl] java implementation |
| − | * | + | * [http://api.openoffice.org/source/browse/api/helperapi/test_documents test_documents] a set of documents ( excel and word ) |
| − | * util/constants | + | * [http://api.openoffice.org/source/browse/api/helperapi/util/constants util/constants] generated building of uno constants |
=== What pieces are worth porting? === | === What pieces are worth porting? === | ||
# the auto generation of the constants type library | # the auto generation of the constants type library | ||
## constants are autogenerated form the <tt>*.api</tt> files located in the <tt>util/ms_api</tt> directory | ## constants are autogenerated form the <tt>*.api</tt> files located in the <tt>util/ms_api</tt> directory | ||
| − | # the object implementations themselves. see the [[porting example]] | + | # the object implementations themselves. see the [[porting example]] and the [[porting notes]] |
# the testdocuments | # 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 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] | ||
| + | [[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
