Apex Code Development You need to sign in to do that
Don't have an account?
AnatolyB calculate field default value immediately
I love the way Probability is calculated from Stage of the Opportunity object.
But how it's done? How can I implement such functionality in my apps?
I've read a about formulas, triggers, apex classes and workflows but they all seem to miss the target because they don't work before "save" button is pressed. Is the visualforce the way to go? Standard Opportunity page doesn't seem to be visualforce.
VF concept: You're correct about this. There is rumour about a true Visual layout editor, but only rumour. You could use third party tools like Flex, etc. But at the moment, it's just a tagging language. (There is an App on the AppExchange that auto-generated a VF page from an existing layout... can't remember it's name... I don't think it's free?)
All or nothing: Well, here I think we're seeing Salesforce's attempt to make things easy for you by giving you what they think you want. And, back when things like the "stagename" and "closedate" fields on the Opportunity were first created, they probably were spot-on for the sales process they were envisioned for. However, tese days they are more problematic than helpful as people want their own customizations.
You can knock some of the fields you're complaining about off the page layout, add your own Formula fields and use that instead. However, it's only calculated after the save, not before. (It's server side, not client sie unless you rewrite it yourself as shown in an earlier post.)
Maintenance: Yep. It tracks dependencies to a certain extent, but at the end of the day if you want to remove a field from an object, for example, and if you have a VF page for that object, you're going to have to go and remove the field.
Of course that's true for most systems.
No Software: That's for marketing folks.
So, it has it's benefits but also drawbacks. The big thing you're getting for free is scalability, reliability, etc. If you wanted to code in some other framework and host it with Amazon, you'd get a lot of that as well. Like anything else, there are tradeoffs. With Salesforce you also have access to the existing user base as an obvious Sales target.
Best, Steve.
All Answers
Here's a little example i coded for you, this is NOT the best way as you shouldn't hardcode the Ids, but i hope it's enough for you to understand the main idea.
Hope it helps !
<apex:page > <script> function changeField(){ //This prefix is autogenerated, you should change these as is generated //on your page. var f1 = document.getElementById("j_id0:j_id2:firstField"); var f2 = document.getElementById("j_id0:j_id2:secondField"); var f3 = document.getElementById("j_id0:j_id2:thirdField"); f3.value = Number(f1.value) + Number(f2.value); } </script> <apex:form > <apex:inputTextarea id="firstField" onchange="changeField()"/> <apex:inputTextarea id="secondField" onchange="changeField()"/> <apex:inputTextarea id="thirdField"/> </apex:form> </apex:page>
- Zeta
gm_sfdc_powerde, Zeta
Thank you very much for your input. Our company uses SF sales for two years and now we are evaluating Force.com as a platform for perspective applications development. Your valuable advices help coming to the right decision.
Yet the conclusions I'm coming to aren't very positive. Let me share my thoughts, I'll greatly appreciate your comments if they are biased, uncomplete or totally wrong.
The functionality in question is relatively simple, it's implemented at standard SF's Opportunity page so I expected it'll be available with small efforts according to the KISS principle. OK, I was wrong. Not a big deal so far.
A bigger concern is Visualforce concept.
First of all it isn't "visual" at all. Dozens or even hundreds lines of code even for a simple page. No visual IDE, no WYSIWYG. No default form generation from existing page layouts, one should write it from scratch. Back to 70s? Oh yes, there are tags now.
Secondly and more harming to me: "all or nothing" approach. Let's suppose the standard page layout is acceptable and user wants to adjust certain aspects of interface or business logic (like percentage default value calulation). I'm very disappointed that there is no way to write a code snippet and hook it to existing form. It's like RAD, 4GL and component development were not invented yet. I guess S-controls are about this but they are deprecated, oops.
And thirdly, I guess maintaining visualfoce code is going to be an issue - it's quite easy to break it by changing data structures - the platform can't track such dependencies.
So where do we come this way? Is it really "no software"? I believe it's rather "yeah! a software" - a lot of it. Whether it's "no" or "yes" software depends not on clouds, multi-tenancy etc. but rather on the number of programmers man-months a customer will need to implement given functionality. SF allows really impressive savings on data development but unfortunately at UI front it rather looses than wins to traditional development.
Disclaimer: all above is my very humble novice's opinion; it was intended to make it provocative but not offensive.
VF concept: You're correct about this. There is rumour about a true Visual layout editor, but only rumour. You could use third party tools like Flex, etc. But at the moment, it's just a tagging language. (There is an App on the AppExchange that auto-generated a VF page from an existing layout... can't remember it's name... I don't think it's free?)
All or nothing: Well, here I think we're seeing Salesforce's attempt to make things easy for you by giving you what they think you want. And, back when things like the "stagename" and "closedate" fields on the Opportunity were first created, they probably were spot-on for the sales process they were envisioned for. However, tese days they are more problematic than helpful as people want their own customizations.
You can knock some of the fields you're complaining about off the page layout, add your own Formula fields and use that instead. However, it's only calculated after the save, not before. (It's server side, not client sie unless you rewrite it yourself as shown in an earlier post.)
Maintenance: Yep. It tracks dependencies to a certain extent, but at the end of the day if you want to remove a field from an object, for example, and if you have a VF page for that object, you're going to have to go and remove the field.
Of course that's true for most systems.
No Software: That's for marketing folks.
So, it has it's benefits but also drawbacks. The big thing you're getting for free is scalability, reliability, etc. If you wanted to code in some other framework and host it with Amazon, you'd get a lot of that as well. Like anything else, there are tradeoffs. With Salesforce you also have access to the existing user base as an obvious Sales target.
Best, Steve.
Steve
OK, great. One more question to make the picture complete: is it practical to develop UI part in other languages/frameworks?
If you mean: Is it practical to keep Salesforce as your data repository, and code the UI in some other system, then I'd have to give it a qualified "no". It's possible, but not all that practical.
You need to have business/control logic somewhere. In Salesforce keeping it in Apex is your only real option. So, if you're going to use the Salesforce Data model, and Apex as a controller, it just makes most sense to also use VisualForce as the front end. (Flex is the exception, and that's something worth considering).
You could, of course, use Salesforce for the Data, code Apex for the controller and expose those Apex control actions via Web services so that your UI, written in anything else you wish, can call those web services for controller actions, however that's a lot of extra coding.
Lastly, you could use the Salesforce API as a pure CRUD database and write your application using any number of other frameworks and then hook in Salesforce. However I'm not sure what's out there to make the integration between Salesforce and other frameworks all that simple. And, since you will, in all likelihood want some "stored procedure" behaviors, then you're still working with Apex, so now you have a code base of Apex as well as your framework code. Sure, you can do this, but you're giving up a lot of the benefits of Salesforce while incurring the cost and limitations. Why not just use Oracle/MySQL for your framework DB, etc.
These are the sorts of architectural decisions which may not always hinge on technical considerations. For example how quickly do you need to get something running? How does it have to scale today vs. a year from now? If you app is always going to have a lot of total users, but with few concurrent users, then perhaps Salesforce costs more than you need and you'd be better off hosting a Grails / Django / Rails application somewhere (e.g. Price is an issue). If integration with other systems is important, then Salesforce's AppExchange, while still somewhat targeted towards the CRM users, does have some good integrations and add on features (albeit at a cost).
It's not to be discounted that if you don't have really distinct UI needs you *can* accomplish a lot just using Salesforce's native features with no coding. It's still customizations, but it's not code until you get to a requirement that you need and can't have without Apex and VF pages. To follow this path further, consider that a typical Salesforce user will eventually have training and "get used" to the default Salesforce behaviors, flow between screens, objects, related lists, etc. Sometimes it's best to just use that stuff out of the box rather than try to protect and defend your users from it. Especially if Salesforce has a lot of your target market.
So, it's all tradeoffs. If you're asking these questions, one might ask why you're considering Salesforce in the first place? Sometimes the "Salesforce as a Framewor" question may not be answerable on pure technical considerations.
Best, Steve.
p.s. This is, obviously all just my humble opinion, I'm sure others have stronger expressions one way or another and probably more cogent arguments. :-)