On 08/11/2015 at 09:45, xxxxxxxx wrote:
When a node is created (and system Init is called) the node is not yet part of the document so you don't have a connection there.
If you have some data that depends on the timeslider, and you don't want to access/rebuild it on the fly every time, then you need to consider a few more situations:
1. The node is cut and pasted (temporarily losing the document connection)
2. The node is saved and loaded
3. The node is copied to a different document with other values in the timeslider
and so on. Your idea of having a boolean marker to check whether your data is built already is basically right, but it does not suffice to cover all cases.
Now, when confronted with this situation, a software developer usually approaches it like this:
Write a function for accessing your "cached data". This function will hide the full complexity of the cache from the caller. It will internally store (in the node) the conditions under which the cache is valid. And it may return null if it fails to access or rebuild the cache, which the caller needs to take into account.
In pseudocode:
GetData (<parameters that are needed to build the cached data>)
{
Boolean rebuildCache = false;
<find the current conditions from the parameters>;
<if that doesn't work, return null>;
if <cache is built already>
{
if <original conditions are different from the current ones>
{
rebuildCache = true;
}
} else {
rebuildCache = true;
}
if (rebuildCache)
{
<throw away old cache, if there is any>;
<do whatever is needed to build your data from the current conditions>;
<if that doesn't work, return null>;
}
return <cached data>;
}
The conditions and the data cache are permanently stored in your tag.
Now, this method does not require any initialization because it checks by itself whether an init is needed. Your start state would be "no data is present" which would force the method to rebuild the cache when it is accessed first.
On every following call, it will determine automatically whether a rebuild is needed. For example, if the cache depends on the FPS of the document, it would look at its current document and get the FPS from there, and then compare it with the FPS that was used lastly to build the cache. If that's the same, then it can use the old cache. If it's different, then the old cache is invalid (because it has been built under different conditions) and needs to be recreated with the new FPS.
The caller must just be aware that there are situations when the cached data cannot be made available (e.g. when the node is not part of a document...), so it must fail gracefully (not causing null pointer exceptions or something).
The nice thing here is that you do not need to listen to messages that may force you to change the cache (and always be in danger that you miss something). You don't need to know when the user changes the minFrame and maxFrame, because the cache access will check these conditions dynamically, and rebuild the cache when needed.
