+ Start a Discussion
kjpetersonkjpeterson 

Replacing SControl buttons with VisualForce buttons

We've implemented quite a few custom buttons on our objects that do simple things like update a status field.  The custom buttons use scontrols to do this and this has worked great.  Our operations manager can understand the simple scontrols enough to update them and reuse the bits and pieces where he needs them.

 

With scontrols being replaced by visualforce, I'm worried that there will be much more development time required to implement very simple things like these custom buttons.  I've found the blog post below that explains how we can achieve the same custom button affect using custom buttons that point to visualforce pages.  The only issue is that I don't think our operations manager would be able to create buttons himself anymore whenever he needs them.  He'll have to create apex classes, write test methods, and figure out how to deploy apex from sandbox to production.  Also, we have so many apex triggers and test methods that it can take 30 minutes to deploy one simple new apex class because of all the other test methods that run.

 

Is there a better way to create these simple custom buttons that just need to update a status field so users don't have to click 5 times to update the field?  Are we going to have to set aside developer time to create these simple buttons now?

 

http://sfdc.arrowpointe.com/2009/01/08/invoke-apex-from-a-custom-button-using-a-visualforce-page/

HarmpieHarmpie
To be honest, I think javascript is not that much simpler to create than some simple APEX / VF. The latter has a dozen of other advantages as well. So from my point of view, you will need a 'developer', whatever way you go.
kjpetersonkjpeterson

I agree that we could create an apex controller that's simple and standard and that they could make simple changes in it like what field gets updated and to what value.  But they still won't be able to deploy apex and handle that process.

 

I guess the biggest change for us is the overhead of having to go through the test case release process.  Previously we could create an scontrol instantly in production, drop the code in, map a custom button to it, and we're done.  Now operations has to halt what they're doing, wait for a developer to get some free time, create the simple controller class, and wait the 30 minutes it takes to release it.

dmsx2oddmsx2od

In other words, instead of shooting from the hip and throwing code into your production org that could affect live data in unexpected ways, you're being forced to adhere to best-practice procedures?  :)

 

Seriously though, if anything, I'd be more scared of the problems that could be created by bad javascript (i.e. the HOURS it would require to fix someone's mistake) than of the time to create code in a sandbox, provide thorough testing, and deploy.  

 

Dont' forget: Writing test code is the only way to protect yourself against imperfect developers.  If you are 100% sure that the people writing your S-Controls and javascript are perfect, then by all means, you've raised a great point.  But if you're even 99.9% sure of their perfection, proper testing is the only way to go.

 

I feel your pain, but you're better off in the long run.