Skip Menu |

This queue is for tickets about the OpenOffice-OODoc CPAN distribution.

Report information
The Basics
Id: 117521
Status: new
Priority: 0/
Queue: OpenOffice-OODoc

People
Owner: Nobody in particular
Requestors: tschoening [...] am-soft.de
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Add some caching to OODoc::File.
OODoc::File provides access to actual data requested in OODoc::Document, ::Meta and such, but is only working on the underlying object state, which may be a file in the file system. If you have loaded such a file and asking for two ::Document instances for e.g. content.xml in two different subs one after another to change different, but compatible things in both of them, you actually only get the most current content.xml in the second stub, if the former saved its changes to the file. In my case I have a template file as part of my software distribution which needs to be read-only for all users of course, but is heavily changed during some process at different places of my software and after all changes applied it's saved to some user specific place. As Document and other instances can be associated with containers, I thought of only passing the container around and have the freedom to create all instances needed wherever I need them. The problem with this approach is that if instances go out of scope, their changes are lost unless they have been saved to the container. But that only works if the file can be created somewhere always for each created and saved instance. While creating such temp files is not that hard of course, I find it easier if one could simply reuse instances already created before and linked to the container. Your File class is already working partly like that: You are able to store all linked instances in general, you can't just easily distinguish between the different instances created for content.xml or styles.xml etc. But that could easily be accomplished using some additional hash ref, where all classes are mapped to exactly one instance in the container and which could be queried on creating new instances in the CTORs in OODoc itself. Instead of always creating new instances, one would query the cache in the container for an instance and reuse that. This way one would only need to keep the container itself around and could easily create/query Document etc. instances from that container without the need to save all changes within the scope of those Document etc. instances.