Revision 505a6560ca4ed204b5caae2fdce8fb7542e18152

Favourite-Feature Update:

- ConfigProcessController.php has seen major improvements:

1. The Site-Access-Routes have been consolidated and are now bundled into just one function, this removes a lot of unnecessary code within the controller as the comparison view and the single site access are now solely handled by one and only one function.

2. Implemented both routes and functions to accommodate for favourite parameters, this means that the favourite parameters have been added to every existing route and have also seen the addition of 2 routes which allow parameters to be saved as favourites and also the favourites to be retrieved for a dedicated view. Due to the implementation a lot of options have been added to the favourites in order to integrate the feature better.

- LeftSideBarMenuBuilder.php has only seen the addition of one extra button, leading to the dedicated favourite parameter view, this was done in order to allow user access to the feature in the first place

- routing.yaml has also seen consolidation of routes and the addition of favourite-parameter routes in order to improve readability and remove redundancies

- the css files have seen some smaller improvements and additions mostly related to the favourite parameters

JS:

- app.js has seen the addition of procedures which allow handling of favourite parameters, this was done so that the favourite parameters would be displayed and usable on the frontend and available to the user

- DownloadParametersUtility.js:

1. saw the renaming of a variable in order to make it fit its actual purpose and intent more and make it more clear what the attribute actually describes

2. Also added another branch which allows specifically the favourite parameters to be downloaded from a file to provide more utility and purpose for the favourites and provide the user with more freedom

- FavourButtonUtility.js saw the added favourite parameters (of all views) being excluded from sending the parameter-keys to the backend, when committing the favourites, which is necessary, since we do not want the parameter values to double up and take more space in the request even though they don't serve any purpose

- FavouritesHandlingUtility.js has been added in order to handle the parameters which stem from the favourites selected by the user and handle these parameters in a way that makes sense

1. The favourites being added into the standard parameter views, will be marked as favourites and their counterparts from the rest of the views will be marked too

2. In the dedicated parameter view, it is possible to select a site access in which to display the favourite parameters and the parameters are being marked as favourites

All of this was done in order to provide the user with more visual feedback regarding the chosen favourites and also provide the parameters with more utility in order to make working with the parameters more effective

- SAListSplitScreen.js has just seen two comments being removed due to them not being of any use anymore

- SynchronousScrollerUtility.js has seen a css selector changed, since all utility buttons on the parameters themselves now feature the "parameter_buttons"-class which allows selecting all unwanted buttons for the duplicated nodes more effectively and dynamically

- Utility.js has seen a small update in its node-comparison-function in order to accommodate for the favourites being present and effective clones from the real nodes

views:

- param_view.html.twig has seen the favourites being added to the template and the associated script file as well

- param_view_favourites.html.twig is a dedicated view for all the favourite parameters

- param_view_siteaccess.html.twig and param_view_siteaccess_compare.html.twig have both also seen the addition of favourite parameters and the corresponding script

- the pagelayout.html.twig has seen some minor refactorings and the addition of a downloader-link, which makes enabling to download a file representation of the parameters easier and more consistent

PHP:

- ConfigProcessCoordinator.php

1. Renamed a parameter in yaml and adapted the if-conditions in the class for them to still work

2. Added a site-access-scouring and updating of the favourite-parameters when the parameters are being saved in the backend in order to allow site-access-dependent displays of the same parameters

3. Fixed a bug in the getSiteAccess-function which caused groups being selected as desired site accesses to have no effect

- ConfigProcessor.php has seen a minor update which sorts all array-keys of all parameters alphabetically now in order to make the display more consistent and easier to read

- CustomSiteAccessParamProcessor.php

1. Refactored existing functions a bit, which makes the organisation of the class more consistent and the functions themselves more readable

2. Tweaked some functions to react better to empty results and given site access dependent parameters

- ParametersToFileWriter.php changed the siteAccessOrAllParameters attribute to fit its role better and adapted its new conditions to the FileWriter, also refactored a lot of functions to increase readability

- ProcessedParamModel.php: Fixed parameters with null values or empty arrays as values not counting as keys with parameter_values underneath, which makes it so that they now posses location_info buttons and the like in the frontend

- ConfigProcessLocationInfoController.php: changed an array-key to make its meaning more clear and updated the function in the class accordingly

LocationRetrievalCoordinator.php: Renamed a special array_key, to make its meaning more clear