S-Controls, an older Force.com technology that has now been superseded by Visualforce, still function on Force.com. However, they are being phased out. You can continue to use existing S-Controls, but restrictions are being placed on creating new ones.
This article should be read if you create or distribute S-Controls. It describes what will and what won't change with the next phase of deprecation that is being introduced in Spring '10, how the deprecation may affect the way you write S-Controls, and what actions you can take as a result.
S-Controls were first labeled as deprecated in the Spring ’09 release. This warning has been present in Setup since the Spring '09 release:
In addition, the following notice was displayed in the Spring '09, Summer '09 and Winter '10 Release Notes:
|Visualforce pages are considered the next-generation of S-Controls and should be used instead of S-Controls whenever possible, both for their increased performance and the ease with which they can be written.
Caution: 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.
As a result, if you've created S-Controls over the past few months you will have been made aware that S-Controls have been superseded and that you should be creating all new user interfaces in Visualforce. Visualforce represents a significant improvement over S-Controls in terms of security, performance, overall system integrity and developer productivity.
In the Spring ’10 release, an additional step forward is going to be taken in S-Control deprecation. With Spring '10, the ability to create new S-Controls is being phased out for orgs that were created after the Spring '10 release, and for orgs created before the Spring '10 release that never contained any S-Controls. In addition, these same orgs will not be able to install unmanaged packages created after February 1st, 2010 that contain S-Controls. The following section will examine who will be affected, what will and won't need to be changed, and what actions you should take.
For developers, the most important thing to know about S-Control deprecation is that existing S-Controls will continue to work as normal after the Spring ’10 release, and that you will continue to be able to edit these S-Controls.
For partners, the most important thing to know is that managed packages that contain S-Controls will continue to be able to be installed without issue after the Spring '10 release. You will also be able to edit the S-Controls contained inside of your managed packages.
The same will be true for unmanaged packages that contain S-Controls, if the unmanaged package was created before February 1st, 2010. These unmanaged packages created before February 1st, 2010 will be considered "grandfathered". Unmanaged packages created after February 1st, 2010 will not be considered grandfathered. Grandfathering of unmanaged packages will be covered in more depth later in this article.
If you are a developer in an org that created one or more S-Controls before the Spring '10 release, you will still be able to edit your existing S-Controls, as well as create new S-Controls after the Spring '10 release. Nevertheless, we strongly encourage you to implement all of your new user interface functionality using Visualforce.
If you are a developer in an org created before the Spring '10 release, and your org does not contain any S-Controls as of the Spring '10 release, you will not be able to create new S-Controls via the web UI, the Force.com IDE, the WebServices API, the Metadata API, Change Sets, or by any other method. In addition, if you are a developer in a new org that was created after the Spring '10 release, you also will not be able to create new S-Controls.
These changes will affect partners and other users of unmanaged packages and the Metadata API, because these, in effect, are ways of creating new S-Controls in your environment. Here are notes on particular distribution mechanisms for S-Controls and the implications of using them:
As a courtesy to existing developers who adopted unmanaged packages, we are excepting them from this phase in the S-control deprecation process. We want users to be able to continue to install these apps. That is why all unmanaged packages containing S-Controls that were created before February 1st, 2010 will continue to be able to be installed in all orgs. These unmanaged packages will be exempted, or "grandfathered" from this advancement in the S-Control deprecation process.
We do want to move away from S-Controls, so any unmanaged package created after February 1st, 2010 containing an S-Control will not be able to be installed into orgs created after the Spring '10 release, and they will not be able to be installed into orgs created before the Spring '10 release that never contained any S-Controls.
If you have been thinking about creating an application and you have been planning to distribute that application via unmanaged packages, you should plan to use Visualforce exclusively for all of your user interface development.
You will be affected by S-Control deprecation if you use the Metadata API to distribute an application that contains an S-Control. The Force.com IDE, Change Sets and the Force.com Migration Tool all utilize the Metadata API. You will not be able to use any of these tools to distribute S-Controls to orgs created after Spring '10, or to orgs created before Spring '10 that never contained any S-Controls.
If you have been distributing S-Controls via the Metadata API, you will not be able to do so to all orgs in the future. You should replace all of your S-Controls with Visualforce pages, or start using packages to distribute your application. If you want to distribute your S-Controls via unmanaged packages in the future, you must create your unmanaged package, and add your S-Controls to it prior to the February 1st, 2010 grandfathering deadline.
This article discussed S-Control deprecation, who will be affected by S-Control deprecation and what actions you should take if you are affected.
Partners that have additional questions or concerns about how S-Control deprecation will affect your application, please log a Partner Support Case in the Partner Portal. Be sure to select the "I have a question or issue relating to a salesforce.com partner program" radio button and then the "AppExchange & Services Listing > S-Control Deprecation" option.
Developers that have additional questions or concerns about S-Control deprecation should post those questions on the AJAX Toolkit & S-Control Developer Board.