[Kexi-devel] addition

[Jarosław Staniek]

I've reviewed the code for html export.
This is the 1st version of the review, incomplete and with possible mistakes.

--
There are two things:

1. You proposed an extension to KexiMigrate API by providing virtual methods 
like drv_ex_setFieldNames().

2. You provided html migration driver.

Ad1.
It doesn't look polished for now, needs more work. First, because you needed 
to extend KexiMigration::Data, it should force us to think about specifics of 
such export types (destinations) like "to HTML".

I guess there's one main difference between database-like destinations and 
static (non-db-like) destinations like HTML: in the latter there's no 
KexiDB::ConnectionData involved (a part of KexiProjectData* destination member 
in KexiMigration::Data).

IMHO we could define a special destination type for cases like HTML/XML 
output. Lets name this "static data output", SDO in short.
There are specifics for SDO compared to database export:
- by default we are creating separate files, one per query
- we're not connecting to a destination engine because there's no such, and 
not mapping source tables' schema to destination tables' schema; in fact we're 
loosing much of the source schema information

Note that we are only dealing with queries, because for tables we're just 
using temporary object created using KexiDB::QuerySchema(KexiDB::TableSchema*) 
ctor.

Ad2.
I've nothing to say about this for now. As Sebastian mentioned, there are many 
possible extensions and improvements.


Notes:
The HTML export will be probably available in 'File->Export' menu, not 
'Migration' menu. GUI will differ from import/export wizard - it will be much 
simpler. Thus I would say we can share less things with keximigrate API than 
currently. Maybe html export should not even implem,ent keximigrate API? 
Especially that we won't implement drv_connect() and similar things...

For current implementation I would propose following split:
A) for reading schema+data, use kexidb itself
B) for writing html use custom code, not implementing keximigrate API at all

Thus we can get cleaner, easier maintainable code.

-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska
  Kexi Developer:
      http://www.kexi-project.org | http://koffice.org/kexi
  Kexi support:
      http://www.kexi-project.org/support.html
  KDE3, KDE4 libraries for developing MS Windows applications:
      http://wiki.kde.org/tiki-index.php?page=KDElibs+for+win32