Re: Review Request: Addition of classes for the centralization of writing a Table to the ODF format.

> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5726/
> -----------------------------------------------------------
> 
> Review request for KOffice and Casper Boemann.
> 
> 
> Summary
> -------
> 
> Warning: Mildly-Long description ahead.
> 
> >Rationale
> 
> Currently we need to save a table in at less 3 different parts:
> * The TableShape (TODO as of now)
> * The PPTX filter
> * The DOCX filter
> (We could include The KSpread table but I don't know if KSpread would like
> to outsource the saving of its file format.)
> 
> So far we have had different implementations, everyone with slightly
> different behavior and different quirks and bugs. For this reason I've
> decided to create a "centralized" way to save a table. Originally I
> started this work in the MSOOXML filters, then moved it to a new library
> but then I realized that the best place was libs/odf.
> 
> >Work done
> 
> The patch introduces several classes that map to the ODF concepts. So far
> I'm mildly satisfied with the results, I think the API promises but it's
> still a long way from complete.
> 
> >Remarks
> >
> >> General
> 
> There are a few remarks I'd like to point out:
> * Give a through review to the API, I want it to be as stable as possible
> so that I can continue building on it. * There's going to be a naming
> clash between KWord's KoTableStyle and the one proposed here. I propose
> renaming KWord's as this class is more generic, plus it is meant to be be
> a public API for our ODF library. A namespace could also be added (Ko)ODF.
> * I added a KoStyle class. As I said, I intended this to be a new library
> before realizing that it should go to the ODF library. I did, however left
> it as it allows less look-ups of the name in the KoGenStyles. * Somebody
> might ask why I added a KoTableProperties, I didn't want to clutter the
> KoTable API with so many properties when its behavior is much more
> important. * I still haven't added the export macro to the classes as it's
> on another one of my branches. * Tests are coming.
> * Documentation is also coming, I have some of it in a branch but I haven't
> heavily invested in it as I still consider this a work in progress. *
> Adaptation in the MsooXml filters is also comming, not released again
> because of unstable API.
> 
> >>Implementation specific
> 
> * KoTable is the owner of all the KoCell's, KoRow's and KoColumn's. There's
> no way to create one of those outside the Table. * KoCellValue maps to
> office:value and its linked attributes.
> * KoCellChild on the other hand represents all the different children of a
> Cell in the table:table-cell. I intend it to be expanded over time to
> cover many more children so that they also can be created using a nice
> API.
As I have had no response, I'll commit what I was able to come up with. I'm a 
bit disappointed that nobody (except for Johannes) showed interest on this 
patch. I'm not completely happy with what I have but there it goes, it'll have 
to be post-commit-reviewed.
-- 
Carlos Licea