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

scontrol, ajax call to our server and - do'able or not?

Inside my single s-control, I'm using beta3.3 sforceclient.js and prototype.js to allow users to create new (proprietary) customer accounts in our web-hosted application environment.  So picture the s-control linked from a Lead or Contact page, walking the user through a list of questions and verifying that key information is correct.

Having done that, my goal was to use prototype's wrapper around Ajax to invoke an application on our server (obviously in our domain) to take the parameters gathered in the s-control, and create a new (proprietary) account, using Ajax updates to show the progress back at the s-control. 

I wanted to avoid handing over the MVC responsibility to the app on our server, which made the ajax route perfect for letting the s-control handle the whole thing.

As expected, I'm getting the refused "" error because of the 2nd domain (ours).  I've got to support IE and FireFox users internally.  Am I hosed (since I can't think of a proxy route to take using the s-control paradigm)?  Dave mentioned in another email that (to paraphrase), "if you're in an s-control, you should be alright" but I don't see how that addresses this restriction, unless I was reading too much into his statement.

Great stuff otherwise.
Thanks, David
Although you'll lose a bit of the progress capabilities, you could post the data to your servers using url parameters and a form.  Another alternative is to create a script tag like

<script src="—firstname=Joe&lastName=Montana"></script>


This publishes the info to your server.  What you return as the javascript can have a function that redirects the page, shows validation errors or whatever.

Read this article for more info.
Ok, so the javascript-on-demand pattern looks pretty good to me because of these two bullets:
  • You can produce snippets of Javascript on the fly - effectively sending back a kind of "behaviour message" advising the browser on its next action. This is a variant of the core pattern described at the end of this section.
  • You can bypass the standard "same-domain" policy that normally necessitates a Cross-Domain Proxy. Provided a server exposes a segment of valid Javascript, it can be extracted by the browser.
Since I was marshalling our tomcat server's response as json speak anyway, it doesn't look like much re-thinking is
required (fingers crossed).

I'll let you know how it goes.  That has got to be a regular issue for folks.
Yes it is.  This is ok if you haven't already spent a lot of time and resources with a standard SOAP web service.  If you have not gone too far down the path, then, by all means.

Let us know how it works out for you.