Every year I see an escalated customer case come in somewhere, that Apex is doing date/times wrong, since somehow the last week of December in 2020 shows up with a year of 2021!
Apex delegates to the very, very commonly used Java SimpleDateFormat for the format string provided to DateTime.format(), and if you open the Java docs you’ll see two values for year next to each other: “Y” for “Week Year” and “y” for year.
Almost nobody knows what “week year” actually means, but Tom Scott summarizes it well, a semi-obscure ISO format that guarantees 52 full weeks per year, even if they don’t align with the calendar year. So, turns out, you really want to be using “y”, not “Y”.
If you're using YYYY instead of yyyy in your java/apex date formats: https://t.co/rC1ocHU1tQ
— Chris Peterson (@ca_peterson) December 30, 2020
The net result of using “Y”? You display December 30th and 31st (depending on Locale) as being in the next year.
]]>every year 😠 pic.twitter.com/2ADptN7WM3
— new baby no sleep just vibes (@isEqualToDan) December 22, 2020
Have to say, he did an outstanding job on the editing.
]]>He and his team did a phenomenal job editing it into something coherent (and enjoyable).
Go check it out: https://developer.salesforce.com/blogs/2020/02/episode-17-spring-20-apex-with-chris-peterson.html
]]>Still, some interesting things in here, not only in my sections about Apex, but the Communities improvements around MDAPI format are massive, and Flow offering system mode is a very interesting new development.
The ongoing improvements about the Invocable Method framework for exposing Apex actions into flow are impressive, and even if you’re traditionally an Apex-centric developer who may have avoided Flow, are something to be aware of since now Invocable actions don’t require many sacrifices, if any, in terms of the Apex API surface to support.
https://www.salesforce.com/video/8176623/
Also, in case you prefer to read instead of watch the Developer Evangelist team did a great writeup on the Apex security features:
]]>In Spring ‘20 the Apex team spent a substantial amount of effort to bring safe lazy loading of describe attributes into the language to attempt to minimize the up-front cost of building Schema.SObjectDescribe instances - especially if you don’t need to read every attribute of it for your use case. Internally, Schema.DescribeSObjectResult instances now keep a private copy of the context they were generated in - what namespace, API version, with sharing/without sharing, and a number of other aspects that can have an impact what’s accessible. For the sake of consistency with non-lazy Schema.DescribeSObjectResult instances, where all the attributes were calculated in a single security context, we have to actually restore the same context in which the describe was generated in, then calculate the attribute.
On that note though, we did discover that unless the “Use Improved Schema Caching” critical update is enabled that this could lead to functional changes in edge cases, especially when mixing and matching API versions in the same request. So to take advantage of this in Spring ‘20 requires at least one of two things to be true:
SObjectDescribeOptions enum value to the getDescribe() call to specifically request lazy loading of properties on use.For ISV partners specifically, where it’s challenging (at best) to ask customers to enable a critical update across the board I’d strongly recommend making use of the new method overload for performance sensitive code paths to ensure your customers have minimal code overhead.
In other words, if you’re working on a managed package and want to ensure your customers are taking advantage of this deferred mode, you’d want your code to look something like
DescribeSobjectResult dsr = Account.SObjectType.getDescribe(SObjectDescribeOptions.DEFERRED);
Deferred mode is especially useful when you aren’t going to need the getChildRelationships() data for a specific SObject type from the describe. As the schema of an organization grows in complexity pre-calculating this method was observed to be one of the most substantial increases in terms of CPU time as it in turns requires running a non-trivial volume of field-level getDescribe() calls to fully populate.
As a best-case example for DEFERRED:
Actual results from a customer's org:
— Zach McElrath (@zachelrath) March 9, 2020
Schema.describeSObjects(new String[]{'User'})[0].isAccessible();
---> takes 700 ms
User.SObjectType.getDescribe(SObjectDescribeOptions.DEFERRED).isAccessible();
---> takes 1 ms
If only describeSObjects() supported DEFERRED...
Take a look at the Apex Developer Guide’s Spring ‘20 version’s topic on Schema.SObjectType.getDescribe(options), which has a full truth table that describes the default behavior in more depth.
While being lazy, especially for describe objects, is amusingly a generally good quality there are situations where it may not be exactly what you want.
One particular case we discovered was Einstein related picklist fields. These have a fairly unique and complex implementation that automatically expands and contracts the valid scope of picklist entries based on what SObject types the current user context has access to. While lazy describe objects make every effort to restore the security context fully sometimes that’s not good enough to guarantee 100% accuracy for this type of field if the valid picklist values are interrogated in a different context. This is very much a case where you’d want to either ensure the same API version across all the code making use of the same describe instance, or else using the FULL describe mode to avoid any potential quirks.
To force the FULL mode, your code would end up looking like
DescribeSobjectResult dsr = Account.SObjectType.getDescribe(SObjectDescribeOptions.FULL);
It is worth calling out that describes are not the only way to inspect the schema anymore, and in many cases may not be the optimal tool. If you haven’t ever made use of the metadata catalog family of standard objects they’re exceptionally well suited for getting specific bits of metadata about fields or objects without needing to search through the whole global describe for a match. For describe-like use cases, you’ll want to pay special attention to EntityDefinition and EntityParticle`. Despite their docs being in the tooling API guide, the same SObjects and fields are available in the data API, which means you can query these in Apex without needing anything special like callouts.
For bonus fun, there’s aspects of entities exposed via the Metadata Catalog entities that aren’t in the Apex describe API, like ExternalSharingModel, which is the best way to detect what specific sharing model any standard or custom object is making use of.
In other words, a query like SELECT NamespacePrefix, DeveloperName, ExternalSharingModel, InternalSharingModel FROM EntityDefinition gives you back a wealth of info that isn’t even available via the describe API at all. And if you further refine it, say with a WHERE NamespacePrefix = 'mine' clause you can end up getting back details about the org schema much more efficiently than looping through Schema.getGlobalDescribe() results, calling getDescribe() on each, and then checking the namespace prefix. Any time you’re looking for a needle in the haystack of org schema you should be considering Metadata Catalog queries before describes.
Take a close look at the tooling API documentation, since there’s a number of hidden gems, like the Publisher field which can be used with the “isSalesforce” value to find standard vs custom objects, i.e.
sfdx force:data:soql:query -q "SELECT NamespacePrefix, QualifiedApiName, ExternalSharingModel, InternalSharingModel, Publisher.isSalesforce FROM EntityDefinition WHERE DeveloperName = 'Case'"
NAMESPACEPREFIX QUALIFIEDAPINAME EXTERNALSHARINGMODEL INTERNALSHARINGMODEL PUBLISHER.ISSALESFORCE
─────────────── ──────────────── ──────────────────── ──────────────────── ──────────────────────
null Case Private ReadWriteTransfer true
null Case__c Private ReadWrite
Total number of records retrieved: 2.
Do note that in this example developerName is not the full API name of the SObject type, which is why we get back both the custom and standard “Case” objects when filtering on DeveloperName, and why we select the QualifiedApiName field, which does distingish between them via the __c suffix. Be sure to read the documentation about metadata catalog types carefully before you rely on specific behavior!
If you have any feedback, please let us know either on twitter or in the comments. I’m especially interested in feedback about the viability of the metadata catalog - let us know performance, functional, or any other kinds of concerns you have upon closer inspection.
]]>This really doesn’t end well with languages like Japanese, where sentence structure can be radically different. Instead, use replacement tokens and String.format (or equivalent).
In other words, labels like: Hi, I'm a label for {0} where you replace {0} with a different label as needed are good. While doing Hi, I'm a label for '+'something' is terrible and will cause horrible pain.
If you apply formatting or hyperlinks to a subsection of your label this task becomes a lot harder than it sounds.
In my case where I did need formatting and token replacement I ended up having to define a helper for my component that builds the ready to use strings, and adding
<aura:attribute type="Object" name="complexLabels" />. Without this, you’ll get warnings (and later on errors) about access checks, since you can’t dynamically create new view properties in lightning, but you can add new keys to an Object. In the helper, process and build the labels, then do something like cmp.set('v.complexLabels', {}); and cmp.get('v.complexLabels').exampleLabel = 'blah';
While outputRichText takes care of filtering out things like XSS attempts, you still make way to do HTML escaping on the $Label values to prevent people from doing silly things like adding image tags in label translations.
String.format-like way, as well as HTMLENCODE in merge expressions.<apex:outputText escape="false" value="{!HTMLENCODE($Label.labelWithReplacementTokens)}">
<apex:param value="<b>{!HTMLENCODE($Label.toReplaceWith)}</b>" />
</apex:outputText>
or, in terms more practical for a demo:
<apex:page showHeader="false">
<apex:outputText escape="false" value="{!HTMLENCODE('<i>this text will not be italicized. but this will be bolded: {0}</i>')}">
<apex:param value="<b>{!HTMLENCODE('see?')}</b>" />
</apex:outputText>
</apex:page>
which nets you:
<i>this text will not be italicized. but this will be bolded: see?</i>
The translation workbench doesn’t include custom objects labels, or their Name field. To get these you can
Considering you’re likely putting this all into source control anyways it seems like the metadata API is the way to go. These translations are stored alongside custom field translations (the kind you use the translation workbench for) in the CustomObjectTranslation metadata type. The various permutations (masculine/feminine, singular/plural, and all other sorts of language specific variants) go into the caseValues element.
Read the docs for the full details, but as something to get you started, you’re likely going to need to add/edit something like this in your object translation metadata files:
<nameFieldLabel>Name Field Label</nameFieldLabel>
<caseValues>
<plural>false</plural>
<value>My Object Label</value>
</caseValues>
<caseValues>
<plural>false</plural>
<value>My Object Labels</value>
</caseValues>
This is a known, and documented, limitation today:
Custom labels referenced in a Lightning component are not automatically added when you create a package containing the Lightning component. To include a custom label in a package, another member of the package, such as a Visualforce page, must reference the custom label.
Still, it blindsides anybody who doesn’t RTFM sufficiently (like me a couple months ago). To get these labels into your package you need to reference them in visualforce or apex. Creating an @isTest apex class for this with no test methods is great, since you don’t have to get test coverage for your labels then. Just make sure you add it to your package, since as a test class nothing will depend on it.
If you’re delivering your app as a managed package that you expect your end users to customize, think about removing the protected checkbox on your labels. The cons of this are that you can’t delete labels later, but the upside is that customers can reference your packaged labels in their customization. This will save them the pain (and expense) of having to have two sets of labels for the same text.
In a non-translation related note, this also makes declarative customization much easier. Protected labels have a cascading nature, so if you use one in a formula field your customers won’t be able to make their own formula fields referencing yours!
If you’re worried about running out of label space, be aware it is a soft limit, although you shouldn’t go crazy just because of that!
]]>
I’m told it will be recorded, and it might be possible to convince me to do another run of it at the San Francisco Developer User Group if anybody wants.
[Update] It was recorded!
]]>([a-zA-Z0-9_-]+":) - worth noting this won’t match all valid JSON due to the lack of handling whitespace before the colon. However the apex JSON.serialize method’s results will consistently match with this.