download prioritization input values and parameter settings as a config.yaml file

[DanWismer]

• For each optimization run, it would be good to have all the New solution input parameters logged and available for download.
• Even better is if we can provide the user an upload option to populate New solution inputs with previous input runs (adding this as a separate issue)

[DanWismer]

@jeffreyhanson , just wondering if you have any comments on the this PR:

I have it now where I save a .yaml of the input and setting configs on the server_export_data:

wheretowork/R/server_export_data.R

Lines 73 to 115 in d66dccb

	### save input values and parameter settings
	input_configs <- list(
	name = app_data$project_name,
	author_name = app_data$author_name,
	author_email = app_data$author_email,
	mode = app_data$mode,
	themes = lapply(x$theme_results, function(x) {
	list(
	name = x$theme$name,
	feature = lapply(x$feature_results, function(x) {
	list(
	name = x$feature$name,
	status = x$feature$status,
	goal = x$feature$goal,
	limit_goal = x$feature$limit_goal,
	max_goal = x$feature$max_goal
	)})
	)}),
	weights = lapply(x$weight_results, function(x) {
	list(
	name = x$weight$name,
	status = x$weight$status,
	factor = x$weight$factor
	)}),
	includes = lapply(x$include_results, function(x) {
	list(
	name = x$include$name,
	status = x$include$status
	)}),
	excludes = lapply(x$exclude_results, function(x) {
	list(
	name = x$exclude$name,
	status = x$exclude$status
	)}),
	parameters = lapply(x$parameters, function(x) {
	list(
	name = x$name,
	status = x$status,
	value = x$value
	)})
	)
	yaml::write_yaml(input_configs,
	file.path(td, paste0(x$get_layer_name(), "_configs.yaml")))

On solution download, the .yaml looks like this
prioritization-2023-01-16.zip

[jeffreyhanson]

Awesome! I only had a quick look, but what do you think about using the $export() methods for the classes (e.g. see here for include class: https://github.com/NCC-CNC/wheretowork/blob/master/R/class_Include.R#L270-L280). These export methods are used when wirting the project YAML metadata file - so might be useful to use them here as well for consistency?

[DanWismer]

I forgot about those $export() methods. Printing them out, I see that the method would export more attributes then we would need (ex. units, legend type, colors, etc.).

What about if I add a new $export method on each ThemeResults, WeightResults, IncludeResults and ExcludeResult ? That way I can call those methods that are designed for pulling relevant attributes distinct to the input configs (name, status, goal, etc.)?

Alternatively, I can use the $export() on each Theme , Weight, Include, Exclude and Parameter class as you mentioned, but then use some type of matching logic in the server_export_data.R script to build out the .yaml with attributes distinct to input configs?

[DanWismer]

... on second thought, I will go with exporting all attributes associated with the $export() method as is. Yes, there will be some extra fields not really needed for configuring input sliders, but I don't see that as a big deal. Plus, the config file will align with the original project input .yaml.

Also, this cuts down on some code I have in this PR which I like!

[jeffreyhanson]

Sorry, just getting to this now. Yeah, you're right that the $export() method will export a lot of extra uneeded stuff (like legends stuff). I agree, I think having the solution file align well with the input.yaml file will be useful. This is because it might help make it easier to verify that the the config file a user has uploaded is indeed for the current project loaded in the app, and keeps things a bit simpler by not having an additional/different file format/structure? Up to you though!