User: fs Date: 2007/02/05 00:33:40 Modified: dba/www/development/projects.html
Log: SQL syntax highlighting File Changes: Directory: /dba/www/development/ ================================ File [changed]: projects.html Url: http://dba.openoffice.org/source/browse/dba/www/development/projects.html?r1=1.3&r2=1.4 Delta lines: +92 -44 --------------------- --- projects.html 29 Nov 2006 08:50:26 -0000 1.3 +++ projects.html 5 Feb 2007 08:33:38 -0000 1.4 @@ -44,16 +44,18 @@ <li> <a href="#form_controls">New/Enhanced Form Controls</a></li> <li> - <a href="#driver_modules">Database driver UI modularization</a></li> - <li> <a href="#form_dialogs">Dialogs with Form Functionality</a></li> <li> + <a href="#driver_modules">Database driver UI modularization</a></li> + <li> <a href="#single_file_backend">HSQLDB: single-file backend</a></li> <li> <a href="#embed_derby">Embed Derby into OpenOffice.org databases</a></li> <li> <a href="#editable_views">HSQLDB: editable views</a></li> <li> + <a href="#syntax_hilight">SQL Syntax Highlighting</a></li> + <li> <a href="#cross_access">native, cross-platform access to MS Access databases</a></li> <li> <a href="#vcards">SDBC driver for vCards</a></li> @@ -277,26 +279,25 @@ <hr style="width: 100%; height: 2px;"> <!-- =============================== --> - <!-- Database driver UI modularization --> - <h3><a name="driver_modules"></a>Database driver UI modularization</h3> + <!-- Dialogs with Form Functionality --> + <h3><a name="form_dialogs"></a>Dialogs with Form Functionality</h3> <h4>description</h4> + <p>When creating a form, the user always needs to bother with a writer (or calc or + draw) document. Very often, this is much too oversized. It would be sufficient + to have a simple dialog which contains all the data access controls. Now that + we have UNO-based dialogs (in the Basic IDE), this is possible in general, as + there already are some basics for doing this. There still would be a lot of + work to be done (not mentioning the concrete design), but since some months, + it's at least possible.</p> - <p>OpenOffice.org Base follows a component-oriented approach for enabling - database access. For this, database drivers are installed in - OpenOffice.org which provide access to a certain (class of) database(s).</p> - - <p>While at the driver level, the implementation is pretty good - modularized, the UI implementation can be improved. Currently, there are - a lot of places in the code with hard-coded information, such as - "database X requires UI option Y".</p> - - <p>The goal of this project is to design and implement a reasonable - architecture for bringing a driver to the UI. The existing - implementation needs to be migrated to this new architecture. As a proof - of concept, an existing currently-external driver (e.g. the - <a href="http://dba.openoffice.org/drivers/postgresql/index.html"; title="http://dba.openoffice.org/drivers/postgresql/index.html";>native PostgreSQL driver</a>) - should be modified so that it can be deployed into an OOo installation and makes - use of the features of the new architecture.</p> + <p>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 (and even do autosizing according to the previous + instance of the same document type, the screen resolution, whatever), which is + nothing you expect from a carefully designed form, where controls are placed at + concrete positions and have a fixed size.</p> <table style="text-align: left;" cellspacing="0"> <tbody> @@ -305,6 +306,7 @@ <td> <ul> <li>C++</li> + <li>UNO</li> </ul> </td> </tr> @@ -312,14 +314,14 @@ <td class="effort_header">useful skills</td> <td> <ul> - <li>OOo's component technology (UNO)</li> - <li>OOo's configuration concepts</li> + <li>familarity with OOo's database access and form API</li> + <li>familarity with OOo's toolkit API (module com.sun.star.awt)</li> </ul> </td> </tr> <tr> <td class="effort_header">estimated effort</td> - <td>2 months</td> + <td>3 months</td> </tr> <tr> <td class="effort_header">difficulty</td> @@ -331,25 +333,26 @@ <hr style="width: 100%; height: 2px;"> <!-- =============================== --> - <!-- Dialogs with Form Functionality --> - <h3><a name="form_dialogs"></a>Dialogs with Form Functionality</h3> + <!-- Database driver UI modularization --> + <h3><a name="driver_modules"></a>Database driver UI modularization</h3> <h4>description</h4> - <p>When creating a form, the user always needs to bother with a writer (or calc or - draw) document. Very often, this is much too oversized. It would be sufficient - to have a simple dialog which contains all the data access controls. Now that - we have UNO-based dialogs (in the Basic IDE), this is possible in general, as - there already are some basics for doing this. There still would be a lot of - work to be done (not mentioning the concrete design), but since some months, - it's at least possible.</p> - <p>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 (and even do autosizing according to the previous - instance of the same document type, the screen resolution, whatever), which is - nothing you expect from a carefully designed form, where controls are placed at - concrete positions and have a fixed size.</p> + <p>OpenOffice.org Base follows a component-oriented approach for enabling + database access. For this, database drivers are installed in + OpenOffice.org which provide access to a certain (class of) database(s).</p> + + <p>While at the driver level, the implementation is pretty good + modularized, the UI implementation can be improved. Currently, there are + a lot of places in the code with hard-coded information, such as + "database X requires UI option Y".</p> + + <p>The goal of this project is to design and implement a reasonable + architecture for bringing a driver to the UI. The existing + implementation needs to be migrated to this new architecture. As a proof + of concept, an existing currently-external driver (e.g. the + <a href="http://dba.openoffice.org/drivers/postgresql/index.html"; title="http://dba.openoffice.org/drivers/postgresql/index.html";>native PostgreSQL driver</a>) + should be modified so that it can be deployed into an OOo installation and makes + use of the features of the new architecture.</p> <table style="text-align: left;" cellspacing="0"> <tbody> @@ -358,7 +361,6 @@ <td> <ul> <li>C++</li> - <li>UNO</li> </ul> </td> </tr> @@ -366,14 +368,14 @@ <td class="effort_header">useful skills</td> <td> <ul> - <li>familarity with OOo's database access and form API</li> - <li>familarity with OOo's toolkit API (module com.sun.star.awt)</li> + <li>OOo's component technology (UNO)</li> + <li>OOo's configuration concepts</li> </ul> </td> </tr> <tr> <td class="effort_header">estimated effort</td> - <td>3 months</td> + <td>2 months</td> </tr> <tr> <td class="effort_header">difficulty</td> @@ -557,6 +559,52 @@ <tr> <td class="effort_header">estimated effort</td> <td>3 weeks</td> + </tr> + <tr> + <td class="effort_header">difficulty</td> + <td>medium</td> + </tr> + </tbody> + </table> + <br/> + <hr style="width: 100%; height: 2px;"> + + <!-- =============================== --> + <!-- SQL Syntax Highlighting --> + <h3><a name="syntax_hilight"></a>SQL Syntax Highlighting</h3> + <h4>description</h4> + + <p>The SQL view of the query designer, which displays, and allows to edit, + raw SQL statements, currently is a mere text input field. It would be helpful + especially to the unexperienced user to have syntax highlighting here: SQL keywords + should be notable, literals should be distinguished, and the like.</p> + + <p>OpenOffice.org already features core components which allow syntax highlighting + in a text field - the most prominent example is the Basic IDE -, so there already is + a foundation to base this feature on.</p> + + <table style="text-align: left;" cellspacing="0"> + <tbody> + <tr> + <td class="effort_header" width="200px">required skills</td> + <td> + <ul> + <li>C++</li> + <li>SQL knowledge</li> + </ul> + </td> + </tr> + <tr> + <td class="effort_header">useful skills</td> + <td> + <ul> + – + </ul> + </td> + </tr> + <tr> + <td class="effort_header">estimated effort</td> + <td>2 weeks</td> </tr> <tr> <td class="effort_header">difficulty</td> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
