Difference between revisions of "User:DrewJensen\Export Manager"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Record Format)
 
(2 intermediate revisions by the same user not shown)
Line 40: Line 40:
 
* Send an XML record back to Report manager for storage.
 
* Send an XML record back to Report manager for storage.
  
 +
== User Interface ==
  
 +
The intial work on the user interface will be to produce an ODT file that uses XForm controls to create and modify the actual XML instance data. Additionally the file will include an embedded DataForm control to handle the interface to the embedded databases storage area for the XML instance data.
  
[[Category:Database]]
+
Two issues here - First, I have never done this and can't say for sure that it will work. But some simple preliminary testing seems to indicate that it should. Second - I have found no example of using the XForm feature this way so again can't say for sure what the limitations of this approach will be.
[[Category:HSQLDB]]
+

Latest revision as of 01:32, 12 September 2007

A user lead effort to add export feature to the current Base capabilities.

Initial work on this will admittedly one persons idea of what an export feature should offer, and how to deliver it. The intent of the original author is to involve other interested persons in the OpenOffice.org user / developer communities.

First decision to make was how to implement the functionality. OOBasic was chosen for two reasons – first, the author is most comfortable in this language – second, OOBasic is the most closely integrated scripting language for OpenOffice.org. This should allow the initial prototyping work to move at a reasonably quick pace.

The long term goal of the project would be to produce a production quality export manger as an add-on for Base. This would be a two phase process – Start with a rapidly prototyped utility and publish it to the general community for use. This steps primary goal is to gather requirements from users regarding how they then utilize the capabilities.

A second phase would be to apply the lessons learned from the prototyping and usage information from users to the design and implementation in a more appropriate scripting tool. JavaScript is the tool being favored by the original author.

This prototype phase will focus on disk file based export of rowset data from a default Base database. However, part of the effort will be to create programmatic interfaces to generate an output stream for a calling routine. The output stream would return exactly the same information that otherwise would have been sent to the disk files.

The manager will use exporting capabilites provided by two basic libraries CSV export and XML export.


Storage Location

In the first round of development the definitions will be stored in a blob field of a table that will be added to the individual database utlizing the ExpMgr.

In other words there will be a init function built into the ExpMgr library. This will utilize the fact that HSQLDB supports categloges, while Base does not directly use them.

A new catelogue will be created, a table will be created in this catelogue that will store such information as needed to manage these export definitions. Because of the way HSQLDB / Base currently work together when embedded the user will not see any reference to this new categloge or table. While scripts are free to get to it, so long as they append the categloge name to the table name.

Record Format

For the initial release a simple XML fomart record will be constructed to store the information needed for the export definition.

A list of data fields for this XML file would include, at a minimum

  • Export Definition Record
    • ExportDefinitionName (string)
    • SourceObjectType (enumeration) [ Table, Query, RowSet ]
    • SourceObjectName (sring)(optional)[ Only valid for type Table and Query ]
    • ExportType (enumeration)[ CSV, XML ]
    • TargetFileName (string)
    • LastExportDateTime (string)

The two worker libraries CSV Export and XML Export will need to expose functions that can

  • Take one of these XML records as input and generate the appropriate export file or bring up the UI within that library for editing.
  • Send an XML record back to Report manager for storage.

User Interface

The intial work on the user interface will be to produce an ODT file that uses XForm controls to create and modify the actual XML instance data. Additionally the file will include an embedded DataForm control to handle the interface to the embedded databases storage area for the XML instance data.

Two issues here - First, I have never done this and can't say for sure that it will work. But some simple preliminary testing seems to indicate that it should. Second - I have found no example of using the XForm feature this way so again can't say for sure what the limitations of this approach will be.

Personal tools