Dependency injection using Custom Metadata Types is a great way to write code on Salesforce that is easily extensible. Even if you never actually end up extending your design Continue reading “Parameterised Dependency Injection via Custom Metadata Types”
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”
Randomness and Oblique Strategies to aid problem solving
In development, or any creative pursuit, we all get stuck. The trick is to know how to get unstuck, without just staring at a blank page. Continue reading “Randomness and Oblique Strategies to aid problem solving”
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”
How Variable Types Operate in the Lightning Component Framework
Attributes in a Lightning Component have declared types. But, with few exceptions, the type you use has never seemed to make much difference. Continue reading “How Variable Types Operate in the Lightning Component Framework”
Salesforce Trigger Handlers Driven by Custom Metadata
Salesforce has a number of recommendations regarding best practice when writing Apex triggers. Two of these recommendations are:
Continue reading “Salesforce Trigger Handlers Driven by Custom Metadata”
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)”
Please don’t use static flags to control Apex Trigger recursion!
Trigger recursion in Apex can be a bit hard to get your head around. Often it is indirect, so hard to diagnose. What can happen is that Continue reading “Please don’t use static flags to control Apex Trigger recursion!”
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!
Don’t build features you can’t afford to maintain
This interesting article comes from an app-developer’s perspective and looks at whether or not you should be adding that new feature to your app.
Continue reading “Don’t build features you can’t afford to maintain”
Hungarian naming conventions were not always evil
As a Salesforce developer, used to working in Apex the lack of strong typing in Javascript can be a challenge.
Continue reading “Hungarian naming conventions were not always evil”
Some shade between the snow in Salesforce Lightning
Salesforce have started to announce some details of what we can expect in Winter 18… One thing to change is the look and feel of Lightning Experience.
Continue reading “Some shade between the snow in Salesforce Lightning”