Introduction
Package.xml is a manifest file between your orgs during deployments. Developers/Admins who have worked on huge projects without proper DevOps implemented and tried to deploy the changes using package.xml know the pain of maintaining it.
Change Set being so easy in terms of accessibility and user friendly, it will take sometime for the salesforce world to move from changeset to package based deployment tools(e.g sfdx).
Recently I was forking with Metadata API using JavaScript and found this JsForce JS library with inbuilt functions to call salesforce APIs. So thought of utilizing it to built something useful. A package.xml generator!
Overview
- let the user select all kinds of components.
- let the user upload a xml file to resume working on that
- store the xml for a day
- be fast in rendering UI
- have easy accessibility
Implementation
We first need to store the component types with some configurable parameters in static resource. I preferred keeping a json file, as the VF page could very easily and efficiently read the file using Vanilla Javascript. And VF was an obvious choice as this tool needs to work in classic as well as Lightning Experience, skipping all the limitations of ltng:outApp.
The json file would look like this with parameters like ObjectAPIName, fieldToFetch, Method, IncludePckg etc.
For the "let the user select all kinds of components" part, this tool uses static resource to store the mapping of metadata types with Metadata API reference. Instead of Metadata API, some component types need SOQL to fetch the list, like Dashboard, Report. Metadata API's listMetdata call requires a folder name to be specified for such component types, not very helpful for our use case.
Now that the configuration part is done, we would also need a VF page to display all the components and let user select them.
Few highlights from the VF page code:
The filter panel with component dropdown and upload package.xml option
Next, we had to "store the xml for a day". Custom Objects are expensive in terms of read and write, we needed something faster & temporary. Platform Cache - it allows you to specify TTL - time to live. So we don't have to clear them explicitly. We are using the current user id and save timestamp to create a unique key for each package.xml. Users can use the generated URL to fetch the package.xml anytime within first 24 hours.
In terms of making the tool "be fast in rendering UI" - we have tried to use Vanilla JavaScript and plain CSS everywhere. All the server calls are using RemoteAction, since this tool might need to show a large number of components time to time, avoiding view state was an obvious choice. And to be honest, I wanted to play around with my new found love - Vanilla JavaScript. :)
In order to - "have easy accessibility", we thought of letting the users click anywhere on the row to select/unselect it. The usual checkbox selection gets very tiresome to click sometimes. So we just thought of letting the users give a bit of relief here. Don't worry, we still have the good old checkboxes too. Each row in the result section is a list item and it contains a inputCheckBox.
Here is a rendered row:
Its nothing but a input checkbox inside a list item.
Following code in JavaScript in function toggleSelection,lets me find the list item that clicked.
Installation
Create a Platform Cache partition with the name - PackageXMLStorage with some Organization storage capacity. No need to make it default. If you are installing it in a dev org, trial capacity can be used.
The github repo comes with a lightning enabled tab - Package Creator. After the installation, access to this tab needs to be given to the targeted users using a profile or permission set.
Click here for GitHub Repo - Package XML Creator
Thank you for your time. Please feel free to post any questions, suggestions.
