Grid in VF page

There are many ways to show the data in the form of gird in the VF pages.

1. apex:dataTable
2. apex:dataList
3. apex:pageBlockTable
4. apex:repeat

apex:dataTable 

• It should be inside of <apex:pageblock> or <apex:pageblocksection>
• <apex:pageblocktable> has a required attribute called "value"
• It uses the standard salesforce page styles
• column headers will be displayed automatically

apex:dataTable

• no need to write inside <apex:pageblock> or <apex:pageblocksection>
• there is no required value
• data can be displayed using custom styles
• we need to specify column headers explicitly

apex:repeat

• there is no proper alignment of data in repeat as compared with datatable
• there is no javascript events like onmouseover,onclick.
• simply data displayed in irregular format

apex:dataList

• An ordered or unordered list of values that is defined by iterating over a set of data.
• It support js event onclick , ondblclick etc

Note: The data set can include up to 1,000 items in all above component. Use Readonly attribute to increase the limit.

Licenses Overview

License provide the specific Salesforce functionality to the user. User must associate with one user license. When creating or editing a Salesforce User, there is a picklist field that lets you assign a specific User License. Profile is dependent on license. To enable additional functionality, you can assign permission set licenses and feature licenses to your users or purchase usage-based entitlements for your organization.

To view a list of the active user licenses in your Salesforce org, click Your Name | Setup | Company Profile | Company Information

 

Salesforce provides the following types of licenses and usage-based entitlements.

1. User License
2. Permission Set License
3. Feature License
4. Usage based entitlement

1. User License:

A user license determines the baseline of features that the user can access. Every user must have exactly one user license.

Salesforce

Salesforce licenses are designed for users who require full access to standard CRM and Force.com AppExchange apps. CRM apps are anything that requires access to Standard Objects like Leads, Opportunities, Forecasts, Cases, and Solutions.

Salesforce Platform

Salesforce Platform licenses are designed for users who only need access to custom apps, and NOT the standard CRM functionality. Salesforce Platform users DO have access to the "core" Salesforce Standard Objects and functionality, like Accounts, Contacts, Reports, Dashboards, Documents, Custom Tabs. Salesforce licenses have much more administrative permissions than Salesforce Platform licenses. If User license is Salesforce, then we can get System Admin as profile.

Chatter Free

Access standard Chatter people, profiles, groups, and files without a Salesforce license at no additional cost.

Chatter External

Allows your clients access to chatter groups at no additional cost.

Communities User Licenses:

There are three Communities licenses for external users: Customer Community, Customer Community Plus, and Partner Community. 

2. Feature Licenses

A feature license entitles a user to access an additional feature that is not included with his or her user license, such as Marketing or Work.com. Users can be assigned any number of feature licenses.

3.Permission Set Licenses

A permission set is a convenient way to assign users specific settings and permissions to use various tools and functions.

4. Usage-based Entitlements Overview

A usage-based entitlement is a limited resource that your organization can use on a periodic basis—such as the allowed number of monthly logins to a Partner Community or the record limit for Data.com list users. 

Apex Design Patterns

A design pattern is a general reusable solution to a commonly occurring problem within a given context. With the help of design, we can avoid much error well in advance. Design Patter ensures the best practices of coding.

The following are a list of design patterns in Apex:

1. Singleton
2. Strategy
3. Decorator 
4. Facade
5. Composite
6. Bulk State Transition 

Singleton

• Repeated execution of a class within a single transaction may lead to exceed the governor limit. This pattern is to reduce repeated instantiation of a class.
• Problem: Developers often write inefficient code that can cause repeated instantiate of objects. This can result in inefficient, poorly performing code, and potentially the breaching of governor limits. This most commonly occurs in triggers, as they can operate against a set of records.
• Implementation: In order to implement a Singleton pattern in apex, the class must instantiate only once. It is implemented by:
• Creating a class with a method that creates a new instance of the class if it doesn't already exist.
• If it already exists, then simply return a reference to the object.
• For example, use a global static variable, before assigning it to value check if it has already a value.

Strategy:

• The Strategy pattern (aka the policy pattern) attempts to solve the issue where you need to provide multiple solutions for the same problem so that one can be selected at run-time.
• Use Case: You need to provide a geographical-based search engine solution where the implementing code can choose the search provider at run-time.
• Implementation: In Order to implement a Strategy pattern in apex, you need to define a family algorithms. It is implemented by:

• Creating the interface class with methods that will be implemented by other classes 
• Covers use of interfaces, Aggregation (Has A) relationship, Method Overloading.

Decorator:

• In some scenarios, we need to show the value only in UI level, but not to store that value in Database. Here we have a Decorator Design pattern to solve this kind of problem. This pattern provides the decorator class which wraps the apex class to provide the extended functionality for the sObject
• Use Case: Whenever the user needs to select the records and process the selected records however select checkbox is not saved.
• Implementation: In order to implement a Decorator pattern in apex, we need to aware that this is not a true implementation the intention is to add the behavior at the run time. It is implemented by:
• Use of wrapper classes inside wrapper class and perform required operation when it is get;set; in vf page instead when the page is loading. We can say it lazy loading. Used in VF page mostly. 

Bulk State Transition:

• The bulk state transition requires a trigger that allows only the eligible record that has changed its state and a utility class to implement the logic. The trigger needs to be framed by its events and the DML type. 
• Use Case: Whenever a developer needs to write the trigger we always consider as bulk and we use the Bulk State Transition Pattern.
• Implementation: In order to implement a Bulk State Transition in apex, use proper filter to check the eligible records using the Trigger Context variable and call the utility class which contacts the method that handles the operation on the bulk operation.

Facade – 

• The intention of the facade design pattern is to convert complex Apex classes into simplified classes or interfaces where groups of classes are either wrapped into one class or only one class is used to delegate responsibilities to the other classes.
• Use Case: Simplifying the execution of classes with complex interfaces (e.g. web service callouts)
• Implementation: Maintainability of Apex code by simplifying the execution of one or complex classes with a facade class. For example, just create a simple class where place code to execute methods/functions of a complex class.

Triggers and Order of Execution

When there is any DML on the Salesforce Record, Salesforce perform the following actions in order:

1. Salesforce loads the original values from the database or initialize the new values.

2. Loads the new value from the request and overwrite the old values.

3. System Validation will run. (In case of Opportunity Line Items Custom Validation will also run)

4. Salesforce executes all the before triggers.

5. Custom Validation will run.

6. Records will save to the database but will not commit

7. Executes all after trigger.

8. Assignment Rule

9. Auto Response Rule

8. Workflow rule

9. Escalation rule

10. Commits all the DML to the database.

11. Post Commit Logic such as sending mails.

Governor Limits

Governor limits are the apex run time limits enforced by the apex run time engine. If you write non-optimized code, your application will get slow and you will see performance issues down the line. But if you write very bad code, salesforce ensures that you will not be using the resource from other applications imposing the governor limit.

Why this is useful: As Apex runs on the shared and multi-tenant environment (Where multiple resources can use the single application at a time), governor limits ensure that code does not monopolize the resource, and each and every user can use the system with no unexpected error.

What happens when code exceeds the limit: If your code exceeds a limit, the associated governor throws the exception error and terminates the request. 

How to take care of governor limits: While writing the code, we must take care of the governor limits and should write the optimized code and should use the best practice of apex. Like avoiding the Too Many SOQL queries, we must ensure the query is not within the “for loop” or particular trigger is not getting fired multiple times. Also if you have a large number of data, we can use the asynchronous class (Batch class)

Important Governor limits:

No of SOQL Query: 100

No of query rows: 50K

No of SOSL: 20

No of DML: 150

No of DML rows:  10K

Maximum Heap Size: 6 MB

Number of future calls: 50

ANT Tool

Prerequisites for Using the Force.com Migration Tool

1.  JAVA (JDK latest version)  use java -version in cmd to know the version of java in your machine                             
2. ANT (latest version) Use Ant -version in the command prompt to know the version of ANT in you machine 
3. Migration Tool (Download latest version from the Salesforce)

Follow the below steps for using Migration Tool:

Step 1: Create the below User Variables
If you have admin right:
Create the below User Variables (Right Click My Computer -> Properties -> Advanced System Settings - > Environment Variables - > User Variables)
If you do not have admin right:
Then Control Panel -> User Accounts-> User Accounts -> Environment Variables - > User Variables

• JAVA_HOME = <path where jdk is installed in your computer>         
• Example - C:\Program Files\Java\jdk1.8.0_25   
• ANT_HOME = <path where ant is installed in your computer>
•   Example C:\Program Files (x86)\apache-ant-1.9.4
• PATH = <path where jdk bin is installed in your computer>; <path where ant is installed in your computer>
• Example  C:\Program Files\Java\jdk1.8.0_25 \bin;C:\Program Files (x86)\apache-ant-1.9.4/bin

Step 2: Setup SFDC Migration tool

1. Extract the Migration Tool Zip file in your local directory, available in Salesforce at :Setup-> Tools ->Force.com Migration Tool
2. Copy the "ant-salesforce" jar file from the extracted folder and paste within lib folder where Ant is installed.
3. Open the Build.properties file from the Migration Tool folder. In the build.properties, update the credentials:
4. Put your package.xml in the folder Migration Tool - > unpackage
5. Retrieve the meta data from the Source org using the below command – Please note the credentials given in build.properties are of source org.  
   ant retrieveUnpackaged 
6. Change the credentials in build.properties and update with the Target org and run the deploy command for the validation as below:ant deployUnpackaged

Issue Faced:

Proxy Setting Issue

Proxy issue can be resolved by configure in the build.xml file as below:

     <target name="proxy">

 <property name="proxy.host" value="*.**.***.*" />

 <property name="proxy.port" value="**"/>

<property name="proxy.user" value=""/>

<property name="proxy.pwd" value=""/>

<setproxy proxyhost="${proxy.host}" proxyport="${proxy.port}" proxyuser="${proxy.user}" proxypassword="${proxy.pwd}" /></target>

Also use depends="proxy" in the target tag as below:

<target name="retrieveUnpackaged" depends="proxy">

      <!--<mkdir dir="retrieveUnpackaged"/>-->

      <!-- Retrieve the contents into another directory -->

 <sf:retrieve username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" retrieveTarget="RetriveFromOGTestForbug" unpackaged="RetriveFromOGTestForbug/package.xml"/> </target>

Heap Size Issue:

If migration code is very large then we can get Heap size issue. I have faced this issue and we have resolved it as below:

1. Go to ANT directory (Where ANT is installed) for example: in C drive as below:                   C:\apache-ant-1.9.4-bin\apache-ant-1.9.4\bin
2. Open ANT batch file in notepade++                                                                                            Set ANT_OPTS =-Xmx2048m                                                                                    JAVA_OPTS = - Xmx2048m in the setDefaultAntHome as below:
   

Version Control

• Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

• The code programmers write changes often. Bugs need to be fixed, features need to be added, and content needs to be changed. Most code is stored as plain old text files, and the code is changed by editing these files. Every time a change is saved, the old version of the file is overwritten with a new one. Unfortunately, no programmer is perfect, and sometimes, mistakes are made. If you make a change to a file, save it, compile it, and find out that something went wrong, it's often helpful to be able to go back to the old version or to get a report of what was actually changed, in order to focus on what may have gone wrong.

Types of Version Control

There are many version control systems out there. Often they are divided into two groups: “centralized” and “distributed”.

Centralized Version Control

• Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

• “Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

• Most modern version control systems deal with “changesets,” which simply are groups of changes (possibly too many files) that should be treated as a cohesive whole. For example, a change to a C header file and the corresponding .c file should always be kept together.

• Programmers no longer have to keep many copies of files on their hard drives manually, because the version control tool can talk to the central copy and retrieve any version they need on the fly. Some of the most common centralized version control systems you may have heard of or used are CVS, Subversion (or SVN), and Perforce.

Distributed Version Control

• In the past five years or so a new breed of tools has appeared: so-called “distributed” version control systems (DVCS for short). The three most popular of these are Mercurial, Git, and Bazaar.

• These systems do not necessarily rely on a central server to store all the versions of a project’s files. Instead, every developer “clones” a copy of a repository and has the full history of the project on their own hard drive. This copy (or “clone”) has all of the metadata of the original.

• This method may sound wasteful, but in practice, it’s not a problem. Most programming projects consist mostly of plain text files (and maybe a few images), and disk space is so cheap that storing many copies of a file doesn’t create a noticeable dent in a hard drive’s free space. Modern systems also compress the files to use even less space.

• The act of getting new changes from a repository is usually called “pulling,” and the act of moving your own changes to a repository is called “pushing”. In both cases, you move changesets (changes to files groups as coherent wholes), not single-file diffs.

• One common misconception about distributed version control systems is that there cannot be a central project repository. This is simply not true – there is nothing stopping you from saying “this copy of the project is the authoritative one.” This means that instead of a central repository being required by the tools you use, it is now optional and purely a social issue.

Git Is a Version Control Application

Git is the application that keeps track of everything related to the changes in your project over time. Git is an open-source program for tracking changes in text files. Let’s start by defining a few key terms:

Repository

• It refers to a storage location, often for safety or preservation. A repository contains all of the project files (including documentation), and stores each file's revision history. Repositories can have multiple collaborators and can be either public or private.

• A repository is the most basic element of GitHub. It’s easiest to imagine it as a project folder. However, unlike an ordinary folder on your laptop, a GitHub repository also offers simple and powerful tools for collaborating with others.

• A repository contains all of the files associated with a project (including documentation), and stores each file’s revision history.

Commit

• A commit, or "revision", is an individual change to a file (or set of files).

• It's like when you save a file, except with Git, every time you save it creates a unique ID (a.k.a. the "SHA" or "hash") that allows you to keep a record of what changes were made when and by who. Commits usually contain a commit message which is a brief description of what changes were made.

Fork

• A fork is a personal copy of another user's repository that lives on your account.

• Forks allow you to freely make changes to a project without affecting the original. Forks remain attached to the original, allowing you to submit a pull request to the original author to update with your changes.

Clone

• A clone is a copy of a repository that lives on your computer instead of on a website's server somewhere, or the act of making that copy.

• With your clone, you can edit the files in your preferred editor and use Git to keep track of your changes without having to be online.

Push

• Pushing refers to sending your committed changes to a remote repository such as Bitbucket. For instance, if you change something locally, you'd want to then push those changes so that others may access them.

Pull requests

• Pull requests let you tell others about changes you've pushed to a Bitbucket repository. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

Fetch

• Fetching refers to getting the latest changes from an online repository (like Bitbucket) without merging them in. Once these changes are fetched you can compare them to your local branches (the code residing on your local machine)

 Working on GitHub Versus Working Locally

• You can make changes to your project directly on GitHub, but most people prefer to work on their local machine so they can make changes in their favorite IDE or text editor. Let’s review a couple important terms:

• The remote repository is a copy of the repository on GitHub. All collaborators synchronize their changes with this, making it the source of truth for the group.

• Local repositories are git repositories stored on a user's computer. If the local directory is linked to a remote repository, then the local repository is a full copy with everything on the remote repository, including all of its files, branches, and history.

The local and remote repositories only interact when you run one of the four network commands in Git: git clone, git fetch, git pull, and git push.

 

Using Git / Basic commands

Git uses a small number of commands to perform its basic operations.

 

 

Overview of the GitHub Workflow

The main steps are:

1. Create a branch off of the master

2. Make commits

3. Open a pull request

4. Collaborate

5. Make more commits

6. Discuss and review code with team members

7. Deploy for final testing

8. Merge your branch into the master branch