Base To-Do
Below is a list of Base-related projects which could be implemented by interested developers. Most of these projects are relatively self-contained, and do not require too much knowledge about OOo's code infrastructure.
Note that the actual project descriptions are not yet moved to this place here, they still reside one of the project's static pages. Your'e encourage to visit this page, as it contains much more information currently.
(So if you want, one of the To-Dos of our project is to move the To-Dos from http://dba.openoffice.org/development/projects.html to this Wiki page.)
Contents
- 1 Joins in dBase queries
- 2 SDBC driver for LDAP directories
- 3 New/Enhanced Form Controls
- 4 Dialogs with Form Functionality
- 5 Database driver UI modularization
- 6 HSQLDB: single-file backend
- 7 Embed Derby into OpenOffice.org databases
- 8 SQL Syntax Highlighting
- 9 HSQLDB: editable views
- 10 Native, cross-platform access to MS Access databases
- 11 SDBC driver for vCards
- 12 New Filter Dialog
Joins in dBase queries
Queries to dBase files can currently contain one table only. Scope of the project is to enhance Base' built-in simple query engine to be capable of executing statements line SELECT table1.field1, table2.field2 FROM table1, table2
. The dBase driver, the text/csv driver, and the Spreadsheet driver would all benefit from this extension.
Be prepared to dig around here before starting the project, the project touches low-level core implementations, including some heavy-to-read STL stuff, so be prepared to invest some time before writing the first line of code.
- required skills C++, SQL knowledge
- useful skills: Lexx and Yacc
- Contact: mailto:dev@dba.openoffice.org
- effort: 4 weeks for an experienced developer
- difficulty: high
SDBC driver for LDAP directories
described in more detail at the here.
New/Enhanced Form Controls
described in more detail at the here.
Dialogs with Form Functionality
When creating a form, the user always needs to bother with a Writer document. Very often, this is much too oversized. It would be sufficient to have a simple dialog which contains all the data access controls.
The advantage would be to not slay the user with things she does not bother – a writer document offers a lot of possibilities which are not relevant for a form. In some cases, a full writer document does even contradict to what users expect from a form – one thing to mention here is that documents are always freely sizable, which is nothing you expect from a carefully designed form, where controls are placed at concrete positions and have a fixed size.
The project is to - extend the dialog runtime engine to (optionally) include data-aware form controls - create a form designer for dialog-based forms (similar to the existing Basic Dialog IDE) - implement persistence of dialog-based forms - embed dialog-based forms into database documents (.odb)
Depending on more fine-grained planning, it might become apparent that not all of this can be done in the scope of a Google Summer of Code project, and reasonable milestones need to be defined.
- required skills C++, UNO
- useful skills: familiarity with OOo's database access and form API, as well as OOo's toolkit API
- Contact: mailto:dev@dba.openoffice.org
- estimated effort: 3 months
- difficulty: high
Database driver UI modularization
described in more detail at the here.
HSQLDB: single-file backend
described in more detail at the here.
Embed Derby into OpenOffice.org databases
described in more detail at the here.
SQL Syntax Highlighting
described in more detail at the here.
HSQLDB: editable views
described in more detail at the here.
Native, cross-platform access to MS Access databases
described in more detail at the here.
SDBC driver for vCards
described in more detail at the here.
New Filter Dialog
described in more detail at the here.