Categories > OpenTBS with ODT >

Suggested change to openTBS to integrate more easily with Doc management systems

The forum is closed. Please use Stack Overflow for submitting new questions. Use tags: tinybutstrong , opentbs
By: James Playfair
Date: 2012-11-22
Time: 02:08

Suggested change to openTBS to integrate more easily with Doc management systems

Typically in an enterprise system, the reporting templates are office/openoffice docs controlled and published by a document management system (sharepoint, alfresco, knowledgetree etc).

Ideally, any application that needs to mailmerge against these stored templates would directly reference these templates using something like get_file_content( url-in-doc-mgmt-system ) and then pass the string to TBS object. 

Unfortunately, the code to unzip the file content resides within the LoadTemplate( ) method, which doesn't provide string-based contents as a parameter.  There is a suggested method of bypassing LoadTemplate() by assigning directly to TBS->Source, but this means that the archive is still zipped and therefore incomprehensible to the merging logic.

Could you guys consider introducing an override to the LoadTemplate( ) method call, or else providing an alternative entry point such as LoadTemplateFromString( ) or LoadTemplateFromURL( ). 

The workaround for now is that I copy the remote file content to a local file on the application system prior to invoking LoadTemplate( ).  However this is less than ideal as it requires handling of consequent multi-threading issues or else some type of random filename generation/cleanup logic in each application.
By: Skrol29
Date: 2012-11-22
Time: 18:09

Re: Suggested change to openTBS to integrate more easily with Doc management systems

Hi James,

Your suggestion is relevant.
It should be technically simple to be able to read the template from a variable (binary string) instead of an actual file stored in the server.
But the better way is probably to open the target file using a PHP stream context on the target file. Therefore reading the archive contents should use exactly the sames techniques (fopen, fread, ...). Since PHP 5, fopen supports stream context.

A stream context can also be better than a binary string because a binary string is stored in the memory available for your script. This can be heavy if you have a big template.

I will have a try.

By: James Playfair
Date: 2012-11-23
Time: 01:19

Re: Suggested change to openTBS to integrate more easily with Doc management systems

That sounds like a great idea.  Let me know if you have success.
By: Skrol29
Date: 2012-11-27
Time: 09:42

Re: Suggested change to openTBS to integrate more easily with Doc management systems

Hi James,

I've looked a bit deeper.
OpenTBS need to read in the template backward and forward in order to find sub-files in the archive. Unfortunately, this is not possible with usual PHP functions when the file is non local.
The solution is to copy the remote file locally.

The point is the function fseek() used by OpenTBS.
The problem is exposed in StackOverflow here:
http://stackoverflow.com/questions/4986335

It could be possible to enhance OpenTBS with a new feature that download the target template in a temporary local file.
This could be nice, but is that a really job of OpenTBS?
By: James Playfair
Date: 2012-11-27
Time: 13:33

Re: Suggested change to openTBS to integrate more easily with Doc management systems

I suspected it might not be so easy.  Thanks very much for your time and effort. 

In my case I'm happy to use the obvious workaround.  My logic is as follows:

- attempt to get the remote template file from Doc management system
- if retrieved OK then overwrite the existing local template file
- merge the data with the local template as per normal

This method has the solid advantage of leaving the most recent local copy of the template around for next time in case the Doc management system is ever offline.

By the way, I love the ease of use of the TBS/openTBS libraries.  Merging to an ODT template works fine for me in both LINUX/Firefox/OpenOffice and Windows/IE/MSOffice environments.