Author: Aidan Harding

Performance Testing of Process Builder vs Apex

The choice between writing custom Apex code or using declarative tools in Salesforce has always been a difficult one to make. Process Builder is capable of more than Workflow was, but it came at a big performance cost. In this article, Roger Mitchell measures that performance cost again. And it looks like things have improved considerably since 2016. Continue reading “Performance Testing of Process Builder vs Apex”

Patterns in Apex: Dependency Injection, Strategy, and Decorator

When you start out in Salesforce development, there seems to be little need for software design patterns. Perhaps because development starts with little triggers doing this and that in a few lines of code. But, as soon as the requirements, codebase, and team-size grow, then the advantages of patterns and other software engineering practices kick in. Continue reading “Patterns in Apex: Dependency Injection, Strategy, and Decorator”

Never mind the half-baked solution, what was the problem? (The X Y Problem)

As a consultant, and as a developer, one of the most useful things you can do is to take a step back. If someone asks you a question about a detail of a solution they are working on, it’s often worth finding out what problem they were originally trying to solve. Continue reading “Never mind the half-baked solution, what was the problem? (The X Y Problem)”

Editing Salesforce Objects in Custom Lightning Components With NO JAVASCRIPT

When it comes to writing custom user-interface code in Salesforce, Lightning is where it’s at. You could write it in Visualforce, but sooner or later you’ll have to convert it to Lightning. Lightning provides a far richer experience. It allows you to view related data more easily, and see that data change in real-time.

One headache for developers has been that doing something like writing a component to update values on a Contact would require page markup, Javascript, and Apex. And Salesforce itself did not check whether the current user had the correct permissions to be viewing/editing this data. Security was an extra requirement that could easily be forgotten.

In Visualforce, the same requirements could all be achieved with a small amount of markup, leveraging built-in Visualforce tags.

Well, as of Spring ’18, Lightning can now achieve the same thing. The combination of two new components, lightning:recordEditForm and lightning:inputField handle all the complexity for us, and we can get on with only writing custom code where it really adds value to the business!

Editing a Contact in Lightning is now as simple as:

<lightning:recordEditForm recordId=”0030Y0000080eMuQAI” objectApiName=”Contact”>
<div class=”slds-box slds-theme_default”>
<lightning:messages />
<lightning:inputField fieldName=”Name” />
<lightning:inputField fieldName=”Phone”/>
<lightning:inputField fieldName=”Email” />
 <lightning:button class=”slds-m-top_small” variant=”brand” type=”submit” name=”update” label=”Update” />
</div>
</lightning:recordEditForm>

Build Secure and Interactive Forms Faster…No custom JavaScript and no Apex needed!