I found one possible solution in the source code for Workbench.
They maintain a mapping structure that includes the pod identifier:
"valuesToLabels" => array(
"login" => array("Login: Production/Developer",""),
"test" => array("Login: Sandbox (test)",""),
"prerellogin.pre" => array("Login: Pre-Release", ""),
"na0-api" => array("NA0 (ssl)","0"),
"na1-api" => array("NA1","3"),
"na2-api" => array("NA2","4"),
"na3-api" => array("NA3","5"),
"na4-api" => array("NA4","6"),
"na5-api" => array("NA5","7"),
"na6-api" => array("NA6","8"),
"na7-api" => array("NA7","A"),
"na8-api" => array("NA8","C"),
"na9-api" => array("NA9","E"),
"na10-api" => array("NA10","F"),
"na11-api" => array("NA11","G"),
"na12-api" => array("NA12","U"),
"na14-api" => array("NA14","d"),
"ap0-api" => array("AP0 (ap)","1"),
"ap1-api" => array("AP1","9"),
"eu0-api" => array("EU0 (emea)","2"),
"eu1-api" => array("EU1","D"),
"eu2-api" => array("EU2","b"),
"tapp0-api" => array("Sandbox: CS0 (tapp0)","T"),
"cs1-api" => array("Sandbox: CS1","S"),
"cs2-api" => array("Sandbox: CS2","R"),
"cs3-api" => array("Sandbox: CS3","Q"),
"cs4-api" => array("Sandbox: CS4","P"),
"cs5-api" => array("Sandbox: CS5","O"),
"cs6-api" => array("Sandbox: CS6","N"),
"cs7-api" => array("Sandbox: CS7","M"),
"cs8-api" => array("Sandbox: CS8","L"),
"cs9-api" => array("Sandbox: CS9","K"),
"cs10-api" => array("Sandbox: CS10","J"),
"cs11-api" => array("Sandbox: CS11","Z"),
"cs12-api" => array("Sandbox: CS12","V"),
"cs13-api" => array("Sandbox: CS13","W"),
"cs14-api" => array("Sandbox: CS14","c"),
"cs15-api" => array("Sandbox: CS15","e"),
"cs16-api" => array("Sandbox: CS16","f"),
"cs17-api" => array("Sandbox: CS17","g"),
"prerelna1.pre" => array("Pre-Release: NA1","t")
)
The problem is that you are using Sets, which are unordered by nature. Since they are not reliably ordered, they may change around at any time, and if a submitted value doesn't match any of the select option values, an error will be raised. There's been some discussion about if select option values should be validated, or if it should be left to the developer to validate the values, but for now, the only workaround is to make certain that the order of the keys can't change. This error actually indicates a deeper problem, which is that if the select items were not validated, you would experience corrupted data in the controller.
This simple fix should resolve the problem:
public class selectController {
public Map<String,List<InnerClass>> mapOfSectionAndItsClass{get;set;}
// This is now a list
public list<String> listOfSection{get;set;}
public selectController(){
mapOfSectionAndItsClass = new Map<String,List<Innerclass>>();
listOfSection = new list<String>();
for(Innerclass__c newContact:[SELECT Name,Low__c,Medium__c,High__c,Section__c from Innerclass__c where section__c!=NULL]){
List<InnerClass> listOfInnerClass = new List<InnerClass>();
if(mapOfSectionAndItsClass.containsKey(newcontact.section__c)){
listOfInnerClass = mapOfSectionAndItsClass.get(newContact.section__c);
}
Innerclass newInnerclass = new Innerclass();
newInnerclass.listOfDropdown= new List<SelectOption>();
newInnerclass.listOfDropdown.add(new SelectOption(newContact.Low__c,newContact.Low__c));
newInnerclass.listOfDropdown.add(new SelectOption(newContact .Medium__c,newContact.Medium__c));
newInnerclass.listOfDropdown.add(new SelectOption(newContact.High__c,newContact.High__c));
listOfInnerClass.add(newInnerclass) ;
mapOfSectionandItsClass.put(newContact.section__c,listOfInnerclass);
}
listOfSection.addAll(mapOfSectionandItsClass.keyset());
}
public pageReference check(){
return NULL;
}
public class InnerClass{
public String value{get;set;}
public List<selectOption> listOfDropdown{get;set;}
}
public class Innerclass2{
public string section{get;set;}
public List<Innerclass> listOfInnerclasses{get;set;}
}
}
Best Answer
I ported Daniel Ballinger's answer here to
Apex
:I tested it and it worked: