This forum allows users to post and respond to "How Do I Do ....." questions. The information contained in this forum has not been validated by K-Rise Systems and, as such, K-Rise Systems cannot guarantee the accuracy of the information.
For situations where multiple controllers need to update the same controls on a widget, I use a submethod to hold the bulk of the logic for easier reimplementation. There are instances where some of the logic does not change after initial load run though, so it would be nice to retain that between subsequent submethod runs to improve performance.
Example:
While compiling a list of data, some is pulled from a 3rd party API. When it can be determined that the list of data hasn't been added to, the existing 3rd party API data would suffice and doesn't need to be retrieved again.
This is currently possible, but can get a bit involved to make work correctly with extra services and configuring to ensure the same workdata structure as if the service was called. It could streamline this kind of optimization if a flag could be set on a service to just include the previous service XML in the workdata of the next run of the same submethod and greatly reduce the complexity and chance for developer error.
Current Flow
Set up steps that could be replaced with a single "Cache Service" flag toggle:
Include the 3rd party API data in the output to the model/controller. (Each submethod call)
Pass 3rd party API data into the next call for that submethod. (Each submethod call)
Put 3rd party API data passed as a parameter into a CreateServiceNodeFromXML to match the structure of the original service.
Required in both current approach and cache suggestion:
Check if 3rd party API data exists and use that instead of recalling the 3rd party API.
Another possible use of being able to cache XML in submethods would be to reuse previous parameter inputs.
Example:
Sorting Controller: Calls a submethod with column to sort records by.
Filtering Controller: Calls a submethod to get records with filters passed in.
Paging Controller: Calls a submethod to get the next page of records.
If the sorting and filtering controllers call a submethod that can cache the inputs, then the paging controller just needs to request the next page of records without worrying about passing in a copy of the filters and sorting values. It would also make future changes to the submethod less likely to break functionality of the different controllers in situations. Like if a filter is added to the submethod, the filtering controller needs to be updated to include it, but the sorting and paging controllers would continue to work as is.
Translation