So I guess wrt version control, the API approach with an extension for loading/saving in folder structure is the better approach.
FlatXML has the disadvantage that files can be very big when binary content is encoded and included. Changing one word in content.xml would result in storing everything again, while the API approach would only result in modified content.xml and maybe some metadata. But of course, there are also advantages in FlatXML: - supported via vanilla OOo, no extension needed - only one file, so no complex change sets with multiple files in version control Not everything can be done with FlatXML files. - Digital signatures only work on ODF packages (So it also wouldn't work with directories) - not sure about document specific persistent configurations Malte. Mathias Bauer wrote, On 06/17/09 08:59: > Alexandro Colorado wrote: > >> sure you cant but some parts only. Some other parts are fixed into the >> OOo internal binary template that will ignore, like meta information >> for example. > > I don't know what an "OOo internal binary template" is, maybe you are > talking about the internal default values for the default paragraph > style. Anyway, this is completely unrelated to the question. > > OOo can store documents "unzipped" and it can do this in two different ways. > > Ths first is the "flat XML" format, usually created with an XSLT based > filter. This will put the whole document (content.xml, styles.xml, > settings.xml, meta.xml) into one single XML file, images will be stored > BASE64 encoded, OOo internal OLE objects will become "inlined", COM > objects will also be stored BASE64 encoded. Every additional "alien" > content will be lost (but - as the name "alien should make clear - OOo > itself does not create such kind of content). But AFAIK there's nothing > from OOo's own stuff that gets lost. > > The second one is available only via API: by passing a parameter (I > don't remember the exact name, but it is documented in the DevGuide) to > the "storeAsURL" call you can get all streams (that usually get packed > into a zip container) written into a folder on disk (that itself gets > the name passed as URL). As this code probably hasn't been used since > years it's possible that it has got some bugs over time. > > This API based solution is a lossless procedure, but loading this > content again will require some external processing or e.g. an > extension. Basically OOo can load this stuff, but without some help it > is not possible to make it do that (main reason: you can't select a > folder in the file picker to load its content). > > Regards, > Mathias > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
