CRM 2011 – Javascript Xrm.Page Basics

I have been looking at the CRM 2011 Javascript SDK, samples. Comparing it to CRM 4 code and getting very angry.  It just wasn’t the same and I wasn’t understanding the SDK, it was written in an odd way and the examples were just much more complex than I needed to get started.  I have also written a good blog entry about the comparison between Javascript CRM 2011 and CRM 4

I could hide sections and tabs ok, using the Page ui but setting variables was really starting to bug me. I could get it too work using crmForm but I wanted to move on and use the new code.

I think the problem is highlighted looking at the new Javascript layout from the technet really shows how Microsoft have split the functionality into logical sections, The picture from Technet shows the logical groups of functionality

The UI bit makes sense but looking at this I couldn’t see how to get the actual fields!!!

there is also a big difference with the actual Javascript you write everything has to get something

Xrm.Page.getAttribute(“hosk_display2”)

Xrm.Page.ui.tabs.get(“hosk_tab1”)

once you get the variable you can then getValue or setValue

Xrm.Page.getAttribute(“hosk_display2”).setValue(“HOSK SET THIS CRM 2011 STYLE”);

Xrm.Page.ui.tabs.get(“hosk_tab1”).sections.get(“Permanent”).setVisible(false);

JavaScript CRM 4 to CRM 2011 converter tool:

http://crm2011scriptconvert.codeplex.com/

Here are some common Javascript functions you will need

Get the value from a field

Xrm.Page.getAttribute(“hosk_field”).getValue() ;

Set the value on a field

Xrm.Page.getAttribute(“hosk_field”).setValue(“new value”) ;

Setting requirement level for a field

Xrm.Page.getAttribute(“hosk_field”).setRequiredLevel(“none”);

There are three requirement levels “none”, “required”, “recommended”.  Required means it must be filled in (red asterisk), recommended is the blue cross and none is obvious.  It’s useful to be able to change the requirement settings dynamically because you can then make users fill in fields after they changed another field or make fields not required.

Hide/show tab

Xrm.Page.ui.tabs.get(“hosk_tab1”).sections.get(“Permanent”).setVisible(false);

hide = setVisable(false)

show = setVisable(true)

You can hide and show a section as well

Some interesting Javascript functions  from this blog tidbits at this blogs:

Call the onchange event of a field

Xrm.Page.getAttribute(“CRMFieldSchemaName”).fireOnChange();

Get the selected value of picklist

Xrm.Page.getAttribute(“CRMFieldSchemaName”).getSelectedOption().text;

Set the focus to a field

Xrm.Page.getControl(“CRMFieldSchemaName”).setFocus(true);

Stop an on save event
event.returnValue = false;

Return array of strings of users security role GUIDs:

Xrm.Page.context.getUserRoles()

god bless the boys from Power Objects

Advertisement

CRM Plugin Registration options explained

Someone was asking me this week about the different deployment options when registering Plugins in CRM.  It is my belief you can store the plugin to disk when you are developing the plugin, this will enable you to debug the file with pdb file.

When you registering the plugin on the live server then it’s better to register it in the database.  The main advantage is the code is safely stored in the database and is accessible to all the deployments e.g. offline/outlook as well as the main crm server.

Having the plugin in the database also makes it easier to update because a few times I have had problems updating plugin dll’s on disk because you have to copy over the exact dll and if you don’t it doesn’t always update the dll so CRM ends up using the previous version of the dll.

The database installation also means if the CRM server is load balanced over a few machines you only have to deploy it once to the database, where as if you installed it on disk you would have to install the plugin on all of the servers.

I have never used the GAC option, we have installed dll’s used by the plugin into the

I found this good post explaining the options.  It also had an interesting comment mentioning ILMerge, which you can download here, this is a .NET tool/utility which merges a number of dll’s into one dll, which is useful for creating plugins for online CRM.

Plugin Deployment Options

The CRM 4 SDK gives some information about the storage options when registering plugins but there are a few more considerations. I got prompted to elaborate on this in a forum post, and I think it’s worth documenting this here as well:

The 3 storage options are: Database, Disk and GAC. The main differences between these are:

• Database: The assembly dll is stored in the database, rather than the file system. The major advantages are that the assembly need only be deployed once if you have multiple CRM servers, and that no additional action is required to restore / redeploy the assembly either during disaster recovery, or if redeploying to an alternate server. This is the preferred option in a production environment
• Disk: The assembly dll is placed in the \server\bin\assembly directory on each server. You have to ensure the dll is placed in the correct place on all CRM servers, so the deployment overhead is a little greater. I normally use this option in development environments as you can redeploy newer versions solely by file transfer, rather than reregistering. Also, if debugging, the assembly .pdb file needs to be placed in the same location; with this option it’s easy to ensure the dll and pdb are from the same build
• GAC: The assembly is placed in the Global Assembly Cache on each CRM server, and again you will have to do this. The GAC does allow multiple versions of an assembly, but CRM doesn’t, so you don’t really gain anything by using the GAC. I don’t think I’ve ever used this option

There is one further consideration. If your plugin assembly has other dependent assemblies, then you can place this dependent assembly in the GAC whichever of the above options you take. However, if you use the Disk option, then the dependent assemblies can also be deployed into the \server\bin\assembly directory