| 41 | | Composite keys - Key used to access the sub keys of a given key. For example the BOREDER key is a composite key for its sub keys – COLOR, INSETS… It can retrieve a list of the kept sub keys. |
| 42 | | Root keys – keeps a key to a resource. It has a sub(T extends Key<?>) method that takes as argument a sub key to get a new key of the same type as the passed one pointing to the same value starting from the root. Example: If the root key is pointing to “PageA/frameA” and the passed key is BORDER the new key that is going to be created will be pointing the value of “PageA/frameA/Border”. |
| 43 | | Simple keys – Keys providing the simpler logic for getting the values of the model – using directly the getRaw() method. |
| 44 | | Templated keys – Keys that support templating. They know about the Simple key pointing to a ResourceRef TEMPLATE and use it to get value for a template key when the getRaw returns null. The TEMPLATE`s value is got from the access and the access is used to open the pointed resource. Then the value is got by it recursively by the template key`s get method. |
| 45 | | Meta keys – Keys getting values that are not kept only in the model. They implement different logic for every instance and are used for things like getting the revision id or some other value that depends on the state of the whole access. |
| 46 | | Security keys – Keys used to get the access options for a certain access. |
| 47 | | The resource model should be immutable so that it is preserved intact in the previous revisions. The only way to modify this model will be by applying change, resulting in new ResourceRevision with a new model. |
| | 41 | Composite keys - Key used to access the sub keys of a given key. For example the BOREDER key is a composite key for its sub keys – COLOR, INSETS… It can retrieve a list of the kept sub keys. [[BR]] |
| | 42 | Root keys – keeps a key to a resource. It has a sub(T extends Key<?>) method that takes as argument a sub key to get a new key of the same type as the passed one pointing to the same value starting from the root. Example: If the root key is pointing to “PageA/frameA” and the passed key is BORDER the new key that is going to be created will be pointing the value of “PageA/frameA/Border”. [[BR]] |
| | 43 | Simple keys – Keys providing the simpler logic for getting the values of the model – using directly the getRaw() method. [[BR]] |
| | 44 | Templated keys – Keys that support templating. They know about the Simple key pointing to a ResourceRef TEMPLATE and use it to get value for a template key when the getRaw returns null. The TEMPLATE`s value is got from the access and the access is used to open the pointed resource. Then the value is got by it recursively by the template key`s get method. [[BR]] |
| | 45 | Meta keys – Keys getting values that are not kept only in the model. They implement different logic for every instance and are used for things like getting the revision id or some other value that depends on the state of the whole access. [[BR]] |
| | 46 | Security keys – Keys used to get the access options for a certain access. [[BR]] |
| | 47 | The resource model should be immutable so that it is preserved intact in the previous revisions. The only way to modify this model will be by applying change, resulting in new ResourceRevision with a new model. |
| 70 | | Every AutoAction class has access to a ResourceChanger which holds the model and can modify it internally without causing any effect on the actual resource model. When a developer wants to change the model he should just create the appropriate ResourceChanger with the model he wants to manipulate and pass it to the AutoAction by setModel() method. |
| 71 | | When managing the model in the performAuto() method developers should use the two methods getRaw(Key<T> key) and setRaw(Key<T> key, T value)of the ResourceChanger. This will transparently register reads and writes for the appropriate operations and thus the change`s effect could be extracted after the method is complete. |
| 72 | | The ResourceChanger should also present several useful helper methods for resource manipulation - makeResource(ResourceRef ref), copyResource(ResourceRef source, ResourceRef destination), moveResource(ResourceRef source, ResourceRef destination), removeResource(ResourceRef ref), makeRedirect(ResourceRef source, ResourceRef destination) and getSub(ResourceRef subRef) which returns an inner Changer and delegates all its logic to its top ResourceChanger. |
| 73 | | The ResourceChanger will be abstract class implementing the ResourceReader interface and providing definitions of the other needed for the perfomAuto() methods. It will be extended by two classes - ModelResourceChanger and SubResourceChanger. |
| 74 | | The SubResourceChanger would implement simpler logic just delegating to the ResourceChanger they are made by. For They would need to know this parent to delegate to and also the ResourceRef by which they are made so that the delegation is made with the appropriate key. |
| | 70 | Every AutoAction class has access to a ResourceChanger which holds the model and can modify it internally without causing any effect on the actual resource model. When a developer wants to change the model he should just create the appropriate ResourceChanger with the model he wants to manipulate and pass it to the AutoAction by setModel() method.[[BR]] |
| | 71 | When managing the model in the performAuto() method developers should use the two methods getRaw(Key<T> key) and setRaw(Key<T> key, T value)of the ResourceChanger. This will transparently register reads and writes for the appropriate operations and thus the change`s effect could be extracted after the method is complete. [[BR]] |
| | 72 | The ResourceChanger should also present several useful helper methods for resource manipulation - makeResource(ResourceRef ref), copyResource(ResourceRef source, ResourceRef destination), moveResource(ResourceRef source, ResourceRef destination), removeResource(ResourceRef ref), makeRedirect(ResourceRef source, ResourceRef destination) and getSub(ResourceRef subRef) which returns an inner Changer and delegates all its logic to its top ResourceChanger. [[BR]] |
| | 73 | The ResourceChanger will be abstract class implementing the ResourceReader interface and providing definitions of the other needed for the perfomAuto() methods. It will be extended by two classes - ModelResourceChanger and SubResourceChanger. [[BR]] |
| | 74 | The SubResourceChanger would implement simpler logic just delegating to the ResourceChanger they are made by. For They would need to know this parent to delegate to and also the ResourceRef by which they are made so that the delegation is made with the appropriate key. [[BR]] |
