Managing Variables

Please post all questions and comments regarding Help & Manual 7 here.

Moderators: Alexander Halser, Tim Green

Post Reply
User avatar
Rob Davis
Posts: 146
Joined: Tue Sep 06, 2011 9:45 am

Managing Variables

Unread post by Rob Davis »

HI
Over time, my set of projects has built up long lists of variables, many of them no longer in use.
Some questions:

1. Is there a way to make a list of 'Variables actually in use (or NOT in use) in this project'?
I'd like to go through each of my projects and prune the unused variables.

2. Is there any way to set a path for the Import/Export of variables? It would help me if all files of variables were stored together in the same folder, so when I import or export the set of variables from different projects, they are kept in a shared location.
I am thinking of managing them collectively in an Excel spreadsheet, using Excel to import/export each file as a column, Eventually, Id probably make one column the list of variable names, and then each successive column, the variable values for that name corresponding to a particular project.

3. An idea - Any suggestion of how I could (easily) use variables for the folder and filename of the current set of variables? e.g.:
AAVVARIABLEPATH=\Projects\ProjectVariables (i.e. NOT part of the Project SearchPath)
AAVARIABLEFILE=Variables_for_ProjectA
User avatar
Tim Green
Site Admin
Posts: 23155
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Managing Variables

Unread post by Tim Green »

Hi Rob,
1. Is there a way to make a list of 'Variables actually in use (or NOT in use) in this project'?
I'd like to go through each of my projects and prune the unused variables.
Not at the moment but it would be a possible addition for the Report Tool. You might want to post a suggestion in the Wish List section. However, such a report would have a serious flaw, by definition: User-defined variables can also be used in skins and templates, and having such a report would encourage users to delete variables that they would then later discover they needed. :roll:
2. Is there any way to set a path for the Import/Export of variables? It would help me if all files of variables were stored together in the same folder, so when I import or export the set of variables from different projects, they are kept in a shared location.
No, and that could be problematic since variable files are most frequently referenced in command line publishing. If you have a standard location and file names you can always set a variable for that in your command line batch file. And for importing into projects you could just have a shortcut to the folder containing your variables in an easy-to-reach location.

3. An idea - Any suggestion of how I could (easily) use variables for the folder and filename of the current set of variables? e.g.:
AAVVARIABLEPATH=\Projects\ProjectVariables (i.e. NOT part of the Project SearchPath)
The easiest way to handle this would be to use command line publishing. Then you could just make multiple batch files with references to the appropriate variables file for each build. You could also use the Publishing Task Manager with a different task for each build you want to produce. The problem there is you need to import the variables to the task rather than having a reference to an external file loaded at publish time. An option for that would definitely be useful -- I'll suggest this to our developers. 8)
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Rob Davis
Posts: 146
Joined: Tue Sep 06, 2011 9:45 am

Re: Managing Variables

Unread post by Rob Davis »

Thanks - even if I didnt get answers that would have suited me :frustration: - your points, of course all make sense.
But I will put the request in to the Wish list - at least that 'Variables in the project' is added to the Reports.

Perhaps my problem of variables and conditionals is a little too specific to our requirements. Once again, your answer points me to command line publishing, and I suppose I shall have to bite that bullet. It would have been simpler if all that side of our requirements had been planned in when the Help was first developed, rather than a long series of grafted-on additions as our needs grew.

Thanks anyway
Post Reply