Using Custom Metadata Type in Salesforce
Custom Metadata Types have great and valuable features which makes it very useful package-able component. It can be used as custom setting and can be deployed as any other metatdata type.
Custom metadata rows resemble custom object rows in structure. You create, edit, and delete custom metadata rows in the Metadata API or in Setup. Because the records are metadata, you can migrate them using packages or Metadata API tools. Custom metadata records are read-only in Apex (that’s the only limitation which I feel makes where you might need to choose Custom setting over custom metadata type).
The biggest advantage Custom metadata type gives is it does not count into SOQL queries for each Apex transaction.You can go through the details of Custom Metadata Type in Salesforce Documentation (https://help.salesforce.com/HTViewHelpDoc?id=custommetadatatypes_overview.htm). You can also go through the implementation guide of Custom Metadata Type (http://resources.docs.salesforce.com/200/9/en-us/sfdc/pdf/custom_metadata_types_impl_guide.pdf).
In this article I will try to explain how we can get the country names based on the country codes in visualforce pages. A very common scenarios where developers generally use list type Custom Setting to store the mapping of Country Codes and Country Names.
We will create a Custom Metadata Type called CountrySetting with a custom field called Country Name. Attached Screenshot is the configuration of the Custom Metadata Type.The Custom Metadata Type has a suffix of __mdt instead of __c (for Custom objects/fields). We can also create a picklist field in custom metadata type (Currently this is in beta phase and hopefully will be available globally soon) .
Lets create some data so that it displays in our Visualforce page. You can click on Manage button and click on New to create the records (Similar to creating records in Custom setting).
Next step is to build Visualforce page which shows the Country Codes and Country Names and the controller required to build that.
I have created an apex class which has a method which returns a list of custom metadata types.
[sourcecode language=”java”]
public with sharing class CountrySettingController {
public list<CountySetting__mdt> getCountrySetting(){
return [Select DeveloperName,MasterLabel, Country_Name__c from CountySetting__mdt];
}
}
[/sourcecode]
Now lets create the Visualforce page.
[sourcecode language=”java”]</pre>
<pre class="codeBlock"><apex:page controller="CountrySettingController">
<apex:sectionHeader title="Custom Settings" subtitle="List Demo"/>
<apex:form >
<apex:pageBlock >
<apex:pageBlockTable value="{!CountrySetting}" var="item">
<apex:column value="{!item.MasterLabel}"/>
<apex:column value="{!item.DeveloperName}"/>
<apex:column value="{!item.Country_Name__c}"/>
</apex:pageBlockTable>
</apex:pageBlock>
</apex:form>
</apex:page>
[/sourcecode]
Here is the attached screenshot of the Visualforce page
If you check the log files , you can see that the method which queries the Custom metadata type does not count towards the SOQL Limit. This was a basic example which shows how we can use Custom metadata type in apex.Since custom metadata types are metadata rather than data, they leverage all the tools Force.com already has for managing, packaging and deploying metadata. This makes them very useful if you are building package-able apps.
This is interesting but the feature seems to be missing something … to wit:
How do you validate that the rows of custom metadata pass your “business rules”. There are no VRs on __mdt, you can’t write triggers on __mdt, and the only thing I could think of was to create a bespoke VF page whose controller did validation in APEX before saving the rows via the APEX metadata API wrapper.
Using your example, verifying no duplicates; verifying that country codes were two character alpha; verifying that two country codes don’t map to the same country name, etc.
Yes you are right but the idea of using custom metadata type is to use for packaging. That way you can send the records as part of the package. Custom Setting had that limitation and Custom Metadata type overcomes that