Difference between revisions of "Helperapi"
From Apache OpenOffice Wiki
(→What pieces are worth porting?) |
|||
Line 22: | Line 22: | ||
# 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. |
Revision as of 21:34, 22 February 2007
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
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
- the existing uno api ( e.g. for calc and writer ) does not provide enough functionality.
- 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.