| Tweet |
Introduction
In part 2 I covered some of the Electron specifics and added a couple of commands around listing and retrieving log files.
In this instalment I'll look at how a command is constructed - the configuration of the parameters and how these are specified by the user.
Command Configuration
As mentioned in part 1, the commands are configured via the app/shared/commands.js file. This defines the groupings and the commands that belong in those groupings, which are used to generate the tabs and tiles that allow the user to execute commands. For example, the debug commands added in the last update have the following configuration (detail reduced otherwise this post will be huge!) :
which equates to a tab labelled Debugging and two command tiles - List Logs and Get Log File :
clicking on a command tile opens up a new window to allow the command to be defined, and here is where the rest of the configuration detail comes into play :
the screenshot above is from the List Logs command, which has the following configuration (in it's entirety) :
the attributes are used in the GUI as follows:
As I work across a large number of orgs, and typically a number of personas within those orgs, the username input is implemented as a datalist - a dropdown that I can also type in to reduce the available options - here's what happens if I limit to my logins :
as the page is constructed, the parameter is converted to an input by generating the datalist entry and then adding the scratch/hub org options as required:
The code that generates the option pulls the appropriate information from the cached org details to generate a label that will be useful:
and this feels like a reasonable place to end this post - in the next part I'll show how the command gets executed and the results processed.
{
name : 'debug',
label: 'Debugging',
commands : [
{
name: 'listlogs',
label: 'List Logs',
icon: 'file',
///////// detail removed //////////
},
{
name: 'getlog',
label: 'Get Log File',
icon: 'file',
///////// detail removed //////////
}
]
}
which equates to a tab labelled Debugging and two command tiles - List Logs and Get Log File :
clicking on a command tile opens up a new window to allow the command to be defined, and here is where the rest of the configuration detail comes into play :
the screenshot above is from the List Logs command, which has the following configuration (in it's entirety) :
{
name: 'listlogs',
label: 'List Logs',
icon: 'file',
startMessage: 'Retrieving log file list',
completeMessage: 'Log file list retrieved',
command: 'sfdx',
subcommand: 'force:apex:log:list',
instructions: 'Choose the org that you wish to extract the log file details for and click the \'List\' button',
executelabel: 'List',
refreshConfig: false,
refreshOrgs: false,
json: true,
type: 'brand',
resultprocessor: 'loglist',
polling: {
supported: false
},
overview : 'Lists all the available log files for a specific org.',
params : [
{
name : 'username',
label: 'Username',
type: 'org',
default: false,
variant: 'all',
flag: '-u'
}
]
}
the attributes are used in the GUI as follows:
- name - unique name for the command, used internally to generate ids and as a map key
- label - the user friendly label displayed in the tile
- icon - the SLDS icon displayed at the top left of the command page
- startMessage - the message displayed in the log modal when the command starts
- completeMessage - the message displayed in the log modal when the command successfully completes
- command - the system command to be run to execute the command - all of the examples thus far use sfdx
- subcommand - the subcommand of the executable
- instructions - the text displayed in the instructions panel below the header. This is specific to defining the command rather than providing help about the underlying sfdx command
- executeLabel - the user friendly label on the button that executes the command
- refreshConfig - should the cached configuration (default user, default dev hub user) be refreshed after running this command - this is set to true if the command changes configuration
- refreshOrgs - should the cached organisations be updated after running this command - set to true if the command adds an org (create scratch org, login to org) or removes one (delete scratch org, logout of org)
- json - does the command support JSON output
- type - the type of styling to use on the command tile
- resultProcessor - for commands that produce specific output that must be post-processed before displaying to the user, this defines the type of processor
- polling - is there a mechanism for polling the status of the command while it is running
- overview - text displayed in the overview panel of the help page for this command
- params - the parameters supported by the command.
Parameters
In this case there is only one parameter, but it's a really important one - the username that will define which org to retrieve the list of logs from. This was a really important feature for me - I tend to work in multiple orgs on a daily (hourly!) basis, so I didn't want to have to keep running commands to switch between them. This parameter allows me to choose from my cached list of orgs to connect to, and has the following attributes:
- name - unique name for the parameter
- label - the label for the input field that will capture the choice
- type - the type of the parameter - in this case the username for the org connection
- variant - which variant of orgs should be shown :
- hub - dev hubs only
- scratch - scratch orgs only
- all - all orgs
- default - should the default username or devhubusername be selected by default
- flag - the flag that will be passed to the sfdx command with the selected value
Constructing the Parameter Input
As I work across a large number of orgs, and typically a number of personas within those orgs, the username input is implemented as a datalist - a dropdown that I can also type in to reduce the available options - here's what happens if I limit to my logins :
as the page is constructed, the parameter is converted to an input by generating the datalist entry and then adding the scratch/hub org options as required:
const datalist=document.createElement('datalist');
datalist.id=param.name+'-list';
for (let org of orgs.nonScratchOrgs) {
if ( (('hub'!=param.variant) || (org.isDevHub)) && ('scratch' != param.variant) ) {
addOrgOption(datalist, org, false);
}
}
if ('hub' != param.variant) {
for (let org of orgs.scratchOrgs) {
addOrgOption(datalist, org, true);
}
}
formEles.contEle.appendChild(datalist);
The code that generates the option pulls the appropriate information from the cached org details to generate a label that will be useful:
let label;
if (org.alias) {
label=org.alias + ' (' + org.username + ')';
}
else {
label=org.username;
}
if (scratch) {
label += ' [SCRATCH]';
}
and this feels like a reasonable place to end this post - in the next part I'll show how the command gets executed and the results processed.
A very good and informative article indeed.It helps me a lot to enhance my knowledge.I really like the way the writer presented his views.I hope to see more informative and useful articles in future.
ReplyDelete