As many of you already know and probably have used, it is possible using javascript to create dynamic drop-down-lists. For instance one drop-down list that selects country and another that lets you select a city in that country. Depending on which country you select, you want the options in the city drop-down to change.
This is a quite common task in MS CRM where javascript is a common tool. In SharePoint however, javascript isn't as common. I am currently working with a colleague of mine, Sebastian Tegel, at a large swedish customer of ours. They had this requirement on some metadata in a SharePoint library so Sebastian and I used the same principles as I usually use in MS CRM to create dynamic drop-down lists in SharePoint. Sebastian has a very nice and instructive posting on his blog on how this is done. Please have a look at it: http://sebastiant.blog.com/2023682/
In the posting before that, he also describes how to create your own custom edit form for a document properties page. This is very useful in these cases, so please have a look at that as well. (http://sebastiant.blog.com//custom+forms/).
Gustaf Westerlund
CRM and SharePoint Consultant
Humandata AB
www.humandata.se
Just one hint when adding Countries in a dropdown list.
ReplyDeleteSince dynamics CRM (at least v3 and v4) only allow numeric values in for dropdowns, the idea of adding countries in a sequential integer order, such as:
Afghanistan = 1
Åland Islands = 2
Albania = 3
[...]
...In my opinion, is a bad this is a bad idea, since if a country is added or removed from the list, it might be difficult to keep track, or even result in mismatches.
I strongly recommend fellow CRM users to use the ISSO 3116-1 unique numeric value for each country instead (source: http://en.wikipedia.org/wiki/ISO_3166-1). So in case a new country is added or removed, you will never have mismatch issues in the future.
following this idea, a country list would look something like this when following the ISO 3116-1 numerical values:
Afghanistan = 4
Åland Islands = 248
Albania = 8
[...]
Just my two cents :)
I agree, a very good comment to avoid future problems and it can probably be generalized to go for other types of attributes aswell where there is a standard enumeration that can be used.
ReplyDeleteGustaf,
ReplyDeleteThanks for the feedback. Another idea that is often discussed is the option to add Country as a new entity. Problem is that it makes it difficult to localise the country names. I made some tests and created a country entity as follows:
* ISO 3116-1 Numeric Value: such as 4, 248, 8
* Name (English): such as Afghanistan, Åland Islands, Albania
* Name (Portuguese): such as Afeganistão, Ilhas Åland, Albania
Then I make a relationship with the Account entity. Problem with this option is that I haven't managed to make the proper country name load as per the loaded user locale.
At the moment, it only shows the ISO 3116-1 values. Say, if I select Afghanistan, it shows "4". The idea is to show "Afghanistan" if the locale is in English, or "Afeganistão" if the system is in Portuguese.
If I managed to make this work, this entity could even hold mor information, such as the country's dialing code, which could then be used to forms jScripts to validate phone numbers.
Thoughts?
Hi,
ReplyDeleteWell, your going out on a stretch to make this work if you want to make it supported.
I think that the best way to do this supported is to create a very small (1 row) aspx-page with cross-frame scripting that communicates with the lookup field (that you should hide on a hidden tab) and sort of renders it as it should. That way, it could probably show the correct country name since you can pick up the users locale via javascript or via the IFrame object arguments.
In general I think that picklists really are preferable when working with this kind of data in a multi-lingual setup since they fully support multi language out of the box. It is a bit problematic when you want to use the same picklist in several entities but I think that there is no simple way out with the current version of CRM. I don't know if MSFT have changed anything in this area for CRM 5 but I don't think so.