In each component I have a compmanagement container, and in it’s local/variables I store a version number of the component. In addition I have a table DAT holding all component’s (newest) version number. Then I have a traverse script which checks if a component is out of date, and if, updates it… As it traverses starting from / nested containers are always updated after the parent is updated.
Works fine, but I was thinking about a different approach, i.e. moving the update logic to the component. So in /component/compmanagement/local/set_variables I would put an expression checking if the local version number is different from the one in the big master table. If it is, it would run a script DAT to update the current component.
Do you think this would work? For example, if
/a
/a/b
/a/b/_/c
are all out of date, is it guaranteed that first /a is updated, and then /a/b is updated?
What could be a problem is that /a/b might not exist anymore, after /a is updated, as it’s was part of the definition of /a and now it’s not in the definition anymore. Or it might not need to be updated anymore, as /a contains the most newest revision after the update.
To make it more complicated, component’s can also have (immune) subnetworks (“/a/b/" in above example), whose content ("/a/b//c”) is independent of the parent component’s definition.
So I think this (partly) dependents on the order in which touch will cook the scene, both on file load and on version number change in the master table.
Do you think this approach might work?
Achim
PS: updating a component is done by setting a clone string, refresh on, refresh off, clear clone string…