function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

AJAX Beta 3.3 - Nulls and Empty Strings ?

Has anything changed in the last day that would mean that a "get" from a Sforce.QueryResults.records[] element would be returning an empty string rather than null ?
I'll have to check.  There was not intention of changing that behavior.
Hi DevAngel - Did you manage to find anything on this ?

Something was changed in the DOM parsing of the soap nodes.  The override to use to workaround this issue is shown below.  It will likely be next week before this regression fix is published.


Sforce.DOM.ParseVal = function(value, name ,desc) {
 var fldDef = desc.fieldMap.getItem(name.toLowerCase());
 if (fldDef == null) {
  var cr = desc.childRelationships.getItem(name.toLowerCase());
  if (cr != null) {
   //This is an object definition for a child relationship
   //This should be a queryResult with all the records of the child object
   return new Sforce.QueryResult(value);
  } else {
   return Sforce.Serialization.DeserializeBean(value);

 } else {
  if (value == null || value.length == 0) {
   return null;
  var fldType = fldDef.type;
  if (fldType == "string" || fldType == "picklist" || fldType == "multipicklist" || fldType == "combobox" || fldType == "reference" || fldType == "textarea" || fldType == "phone" || fldType == "id" || fldType == "url" || fldType == "email") {
   return value;
  } else if (fldType == "boolean") {
   if (value.toLowerCase() == "false") {
    return false;
   } else {
    return true;
  } else if (fldType == "currency" || fldType == "double" || fldType == "percent") {
   return parseFloat(value);
  } else if (fldType == "date" || fldType == "datetime") {
   return Sforce.Util.FromIsoDateTime(value);
  } else {
   return value;


Not to be too big a pain in the ass, but, shouldn't Beta 3.3 be *frozen* at this point?

I mean, if there are going to be changes to the behavior, shouldn't this be done in third digit point releases
or some other control mechanism so we don't have to be going back and discovering why things break. 
Perhaps there is some "announcement" place I'm not aware of where the listings of the fixes in any
particualr time period are published?  That would help.

</soapbox>  :-)

Thanks, Steve Bower.


I agree with Steve.

We have an app on the AppExchange that temporarily broke last week because of this. I have coded in a work-around myself but here's the thing - I only found the fault by accident and hopefully not many potential customers (of either our app or Salesforce itself for that matter) found it.

I fully support the idea that once we know about a beta (does it still need to be beta?) release being available to write against, it should be a frozen release version. These changes could have been made on beta 3.4 and an announcement could have been made, on the announcement board, of it's availability.

I know you're going to say I should take a copy of all the js files (is it 6?) and place them in documents within Salesforce. My argument is that that is a faff for every installation, and shouldn't need to be done with a proper version control mechanism in place.

Especially if I regression test and release the app against a new toolkit version...

... If I have existing customers on beta3.3 say, and  I want them to use beta3.4, then I will have to send them all of the javascript that makes up the new version of the toolkit plus my changed S-Control javascript. There is then the potential that they upload some but not all of the files and it breaks the application. I would rather just send them my new S-Control javascript.

(When versioning is available on the AppExchange it might be a different story)

This AJAX stuff is really powerful and we can write some really cool stuff, but if someone goes and test drives any application on the AppExchange and it blows up, then potentially we could all be losing customers


No, beta3.3 is not frozen.  You will not see any changes that warrant a dot release.  Any changes, including the one that introduced the bug that is the topic of this thread, were for "minor" bug fixes.

The behavior change was unintentional.  Unfortunately, until the AJAX toolkit becomes a supported product, the chance of bugs and regressions will exist.

I can assure you that there will be no new beta versions beyond beta3.3 due to the wide adoption and lack of resources to assure quality. 

There will continue to be bug fixes to existing behavior and functionality as appropriate.