What is governor limit in salesforce?

Governor limit are run time limits/exceptions enforced by the apex runtime.Because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces limits to ensure that runaway Apex code or processes don’t monopolize shared resources.

1. Per-Transaction Apex Limits
2. Per-Transaction Certified Managed Package Limits
3. Force.com Platform Apex Limits
4. Static Apex Limits
5. Size-Specific Apex Limits
6. Miscellaneous Apex Limits
7. Push Notification Limits

function to show dialog/popup box using script

function showSimpleDialog()

{ 

var sd = new SimpleDialog("Test"+Dialogs.getNextId(), false); 
var rurl = '/{!Contact.Id}/e?retURL=%2F{!Contact.Id}&RecordType=01261000000Xnij&00N6100000DOeVX=Active'; 

sd.setTitle("Alert"); 
sd.createDialog(); 
window.parent.sd = sd; 
sd.setContentInnerHTML("<form action="+rurl+" method='POST'><p align='center'><img src='/img/msg_icons/warning32.png' style='margin:0 5px;'/></p><p align='center'>The related contact must have an active campaign response.Please add a response and afterwards,update the contact status to 'completed' before creating the opportunity.</p><p align='center'><button class='btn' onclick='window.parent.sd.hide(); return false;'>Cancel</button></p></form>"); 
sd.show(); 
}

 Sent with Mailtrack

Setting Read-Only Mode for Controller Methods

Visualforce controller methods can, with some important limitations, use the Apex ReadOnly annotation, even if the page itself isn't in read-only mode.

Visualforce controller methods with the @ReadOnly annotation automatically take advantage of read-only mode. However, restrictions on the @ReadOnly annotation means that, for Visualforce controller methods, a read-only method must also have the @RemoteAction annotation. The @RemoteAction annotation requires that the method be:

• Either global or public
• static

Enabling read-only mode by using the @ReadOnly annotation must be done on the top level method call. If the top level method call doesn't have the@ReadOnly annotation, the normal restrictions on maximum queried rows are enforced for the entire request, even if secondary methods are annotated with @ReadOnly.

Using the @ReadOnly annotation on a controller method allows you to retrieve a larger collection of records as the result of a Visualforce expression. However, it doesn't increase the maximum number of items in a collection for iteration components. If you want to iterate over larger collections of results, you need to enable read-only mode for the entire page.

ReadOnly Annotation

The @ReadOnly annotation allows you to perform unrestricted queries against the Force.com database. All other limits still apply. It's important to note that this annotation, while removing the limit of the number of returned rows for a request, blocks you from performing the following operations within the request: DML operations, calls to System.schedule, calls to methods annotated with @future, and sending emails.

The @ReadOnly annotation is available for Web services and the Schedulable interface. To use the @ReadOnly annotation, the top level request must be in the schedule execution or the Web service invocation. For example, if a Visualforce page calls a Web service that contains the @ReadOnly annotation, the request fails because Visualforce is the top level request, not the Web service.

Visualforce pages can call controller methods with the @ReadOnly annotation, and those methods will run with the same relaxed restrictions.

Collection Size Error when accessing Visualforce page

Visualforce is not designed to display more than 1000 records on the same page. Generally speaking, if your SOQL's are returning more than 1000 records and you attempt to display these records on a VF page, you will receive this error.

You can implement two solutions for this issue:

1- You can either limit the number of records you are trying to display to be less than 1000 or use pagination to display the records in different pages

2- You can use the @ReadOnly annotation on the method that retrieves the records or on the entire visualforce page. You can find more information about this here.

Deleting Files from an Organization

The package.xml file is a project manifest that lists all the components to retrieve or deploy. Although you can use package.xml to add components, it’s not sufficient to delete them. 
To delete files, create a delete manifest that’s called destructiveChanges.xml. The format of the delete manifest is the same as package.xml, except that wildcards aren’t supported

The following sample destructiveChanges.xml file names a single custom object to be deleted:

1	<?xml version="1.0" encoding="UTF-8"?>

2	<Package xmlns="http://soap.sforce.com/2006/04/metadata">

3

<types>

4	<members>MyCustomObject__c</members>

5	<name>CustomObject</name>

6

</types>

7	</Package>

To deploy the destructive changes, you must also have a package.xml file that lists no components to deploy, includes the API version, and is in the same directory as destructiveChanges.xml:

1	<?xml version="1.0" encoding="UTF-8"?>

2	<Package xmlns="http://soap.sforce.com/2006/04/metadata">

3	<version>38.0</version>

4	</Package>

• To bypass the Recycle Bin, set the purgeOnDelete option to true.
• If you try to delete some components that don’t exist in the organization, the rest of the deletions are still attempted.