Another notice of S-control end-of-life
Last Updated on Friday, 6 March 2009 02:51 Written by Steve Friday, 6 March 2009 01:26
Sonny Cloward spotted this in the S-Control editing interface:
S-controls have been superseded by Visualforce pages. Salesforce will, sometime after January 2010, remove the ability to create and distribute new s-controls. Existing s-controls will be unaffected.
At Dreamforce it was made clear that this technology is on the way out. S-Controls are being replaced by VisualForce. I have gushed about VisualForce in the past. I think that it is a design marvel–the balance of simplicity and power continues to blow me away. The more I use it, the more impressed I am.
But with all it’s power and simplicity, VisualForce currently can’t do everything that S-Controls can do.
S-Controls run in your browser and use the API when communicating with Salesforce. How many interactions they can do with Salesforce are limited by the number of API calls your organization can make and by the amount you can ge done before your browser connection times out. You can actually get a lot of data processing done this way.
VisualForce is light-years ahead of S-Controls in how it works. It hands all the Salesforce heavy lifting to Apex, which runs on the server. This is a great idea–why send all that data across the wire to you only to send it back to Salesforce? Theoretically, you could process a whole lot more on the server and get very fast response. But, because the server is a shared resource, there are operational limits to the amount of processing you can do. These limits are hard and fast, and haven’t budged since Apex was announced two years ago.
There are a number of use cases where I can’t get VisualForce to do what S-Conrols can do for me. One such use case is when you are trying to compare two lists of data and look for similarities. Like comparing the Campaign Memberships of two Campaigns, or looking at all Campaign Members on a Campaign and flagging all the Accounts that are represented more than once. I can’t figure out how to use VisualForce and Apex to handle these kinds of operations that may be comparing lists of 1000+ members.
I’m all for killing S-Controls–I haven’t written a new one in over a year, it seems. But I have some that I haven’t re-written as VisualForce, because I can’t replicate the functionality. I hope that before S-Controls are killed, VisualForce can do the kinds of processing that S-Controls can do, and more. I hope Salesforce.com figures out how to take the operational shackles off VisualForce and Apex in a way that good coders can use to do much more intensive processing than is currently possible.
[Update]: Via twitter, Simon Fell reminded me that VisualForce pages can interact directly with the API. I’d rather be able to use Apex to touch 5000 records, but nice to have this option. Thanks Simon!
Comments
Powered by Facebook Comments
Another current gap between s-controls and VisualForce – s-controls can be used as a dashboard component; but VisualForce can not. Or correct me if there is a way to do this!
Rhonda, yes there are a couple of gaps in terms of what you can do with a Visualforce page vs. Scontrols and dashboard components is one such example. The good news is that should be addressed in the upcoming Summer ’09 release.
As the product manager for Visualforce and formerly Apex I can say I’ve heard this type of feedback before about the limits. Recall that the limits for Apex are per request and as such a common pattern, not unlike what you are doing with the API through the Ajax Toolkit, is to chunk across requests. This doesn’t necessarily address all cases but I think people tend to revert to calling the API directly without thinking how they can chunk the processing with straight-up Visualforce and Apex.
In general our approach to unbounded operations in Apex, from a row-level perspective, is to do the long running process asynchronously. You may have already noticed the Batchable interface in Apex which will become more available in the coming releases.
With batch Apex and enhancements to Visualforce we hope that use of the API directly from the client (or even multi-request operation spreading due to limits) will no longer be necessary but in the meantime you have the same access there as you do from Scontrols today to fill in any gaps – try to do so only when necessary
Thanks for this post, Steve. Always good to get feedback on the service! I’d be happy to review your specific case if you want to send it to me.
Thanks for the info Andrew. Any idea if list size is going to increase in Apex? Right now lists are limited to 1000 members. Comparing two lists of 3000 members is trivial in JavaScript, but I think would be pretty complex if you had to break each list into lists of 1000.
One key differentiator at the moment is that visualforce is hosted from a different domain (force.com versus salesforce.com) which is done to provide added security benefits (important benefits). The problem is that when you add visualforce to an iframe on the homepage, or to a page layout, there cannot be any communication between the vf page and the main page (cross-domain scripting)… but I’ve heard that help is on the way as the force.com development team is working on ways to automate resizing of iframes and perhaps other actions you might have tried to do in your now “illegal” scripting. So, hopefully those features will be in place BEFORE S-Controls are taken out back and bashed with a shovel.
That’s good to know that Vf can access the API, I have a scenario in which APEX can’t do the job: changing a password. While it’s not good security policy in general, we do have a biz case that required us the latitude to do so and for now my Vf page calls and s-control to get the dirty work done. I figured it’d survive the s-control d-day but never be editable post-2010.
Salesforce can cutoff support for it without disabling it. As time goes on there won’t be a point, but a use-at-your-own-risk disclaimer would be better than arbitrarily turning off the new button. Perhaps it can be re-enabled upon customer request. It might be prudent to create a bunch of place holder scontrols just in case.
The bigger question is will salesforce be discontinuing support for the Ajax toolkit?
Regarding distribution, it seems to make sense that new AppExchange packages won’t support scontrols but existing packages will continue to work. I am not sure what the official stance will be there.
True. I think the best course is to migrate what you can, and don’t create any new scontrols unless you have to. Apparently you can paste the entire contents of an scontrol into a VF page and it will work. I haven’t tried it but that has been reported.
Michaelforce. I actually posted an idea about a week ago on exactly what your talking about. The problem of force.com vs. salesforce.com . It doesn’t have alot of points right now, but hopefully mentioning it here will be a good promo. Here’s the link:
http://ideas.salesforce.com/article/show/10095804/Host_visualforce_on_the_same_domain_as_the_org
What have you guys heard about this getting solved? Do you know if it will happen soon?
Also, just to be clear, I to love visualforce and almost everything about it. But to me, one of the biggest issues is picklists. Dynamic Picklist not being supported in visualforce can be really frustrating, also the fact that picklist values aren’t filtered automatically depending on the record type, like they are in standard page layouts. Anyway, I think that’s a big pain point. Andrew, any feedback on this?