I don't know if many people know this, but under the hood Force.com runs on JSF. Salesforce doesn't publish this information anywhere that I know of (if you know please share!). As a developer, if you are familiar with JSF than when you start working with Force.com you should be able to make the transition fairly smoothly. This hopefully should remove the sticker shock from anyone who is looking at implement Salesforce.com and thinks "Visualforce and Apex? I don't have people who can support that?". Well, if you have Java developers, there's a good chance they can use their existing skill sets to help support your Force.com implementation.
The two major components of the Force.com platform are Visualforce and Apex. The first part is Visualforce. You can think of Visualforce as a tag library which wraps around JSF tags. Instead of having a tag like <h:datatable> in JSF the Visualforce equivalent is <apex:datatable>. You'll find many of the JSF components (Templates, Compositions, PanelGrid, OutputText, InputText, ETC) have almost identical wrappers in Visualforce with the major difference being the taglib using the <apex:> name space.
The second major component is Apex. Apex is essentially a wrapper around Java. In JSF you have backing beans for your JSF pages. In Force.com, your backing bean is an Apex Controller. The Java Bean naming convention applies just like it does in JSF. So if you have a property called "accountName" with a getter of "getAccountName()" in your backing bean, you would acces it in JSF by #{beanName.accountName}. Its the same way in Force.com except when you bind to your Apex Controller Class attribute to the Visualforce page you use {!apexClass.accountName}.
There are many more similarities to JSF. For example, in your Apex Classes the ApexPages classes are similar to the FacesContext classes. There are lots of other examples but for the scope of this blog just wanted to point out that basic similarity between JSF and Force.com for folks who didn't know they had a relationship.
Lessons learned and technical ramblings from 15 years in the exciting field of Information Technology, and specifically Software Development. Strong emphasis on Platform as a Service and Salesforce Platform for enterprise software development.
Stat Tracker
Friday, March 18, 2011
Monday, February 14, 2011
Infamous Rookie Error : System.QueryException: List has no rows for assignment to SObject
System.QueryException: List has no rows for assignment to SObject
I see this error time and time again in the developer boards, when I'm working with junior developers, or working with developers who are new to the platform. So I figured I'd write up a quick post about it and how to solve it. Lets say I have a trigger or controller or any Apex code which needs to execute a SOQL query.
For the purpose of this example, lets just say I'm going to query on Account Name. In this example, I expect all my Accounts to have unique names. Below is how a junior developer may write this query:
Example Problematic Apex Code:
The problem? If this SOQL executes and there are no matches for inputName, than this statement will throw the System.QueryException. Why? Behind the scenes I think Apex is trying to take a result from List in memory (The list of results from SOQL) and convert the first row into a SOBject for assignment to your variable. Since there are 0 results, it throws the exception.
There are 2 ways to solve this:
1. You can wrap this in a Try/Catch block like so:
2. You can store the results in a List<SObject> instead of just an SObject and grab the first result like so:
Its as simple as that. What method do I prefer? Personally, I like storing my results in Lists. Why? Well I usually already have try/catch logic to handle exceptions, and nesting additional try/catches can get a bit bulky. Its just a preference is all. Both approaches work perfectly fine. And depending on how your write your code, it may be preferable to do the Try/Catch approach. Its really up to the developers own taste.
Bottom Line - Its an easy problem to solve if you know the details, and now you know!
And knowing is half the battle!
I see this error time and time again in the developer boards, when I'm working with junior developers, or working with developers who are new to the platform. So I figured I'd write up a quick post about it and how to solve it. Lets say I have a trigger or controller or any Apex code which needs to execute a SOQL query.
For the purpose of this example, lets just say I'm going to query on Account Name. In this example, I expect all my Accounts to have unique names. Below is how a junior developer may write this query:
Example Problematic Apex Code:
Account lateAccount = [Select Id, Name from Account where Name =: inputName limit 1];
The problem? If this SOQL executes and there are no matches for inputName, than this statement will throw the System.QueryException. Why? Behind the scenes I think Apex is trying to take a result from List in memory (The list of results from SOQL) and convert the first row into a SOBject for assignment to your variable. Since there are 0 results, it throws the exception.
There are 2 ways to solve this:
1. You can wrap this in a Try/Catch block like so:
Account lateAccount = null;
try{
lateAccount = Account lateAccount = [Select Id, Name from Account where Name =: inputName limit 1];}
Catch(Exception e)
{ system.debug('There was an exception, but we can just set the lateAccount to null and continue on....);}
2. You can store the results in a List<SObject> instead of just an SObject and grab the first result like so:
Account lateAccount = null;
List<Account> resultAccounts = [Select Id, Name from Account where Name =: inputName limit 1];
if(resultAccounts.size() > 0){lateAccount = resultAccounts.get(0);}
Its as simple as that. What method do I prefer? Personally, I like storing my results in Lists. Why? Well I usually already have try/catch logic to handle exceptions, and nesting additional try/catches can get a bit bulky. Its just a preference is all. Both approaches work perfectly fine. And depending on how your write your code, it may be preferable to do the Try/Catch approach. Its really up to the developers own taste.
Bottom Line - Its an easy problem to solve if you know the details, and now you know!
And knowing is half the battle!
Saturday, February 5, 2011
Force.com Sites - Creating a Personal Website in 15 minutes and 15 dollars.
Do you have 15 minutes and 15 dollars? Do you want to create your own personal website and have the full power of an easy to use database on the back end? Well, if so then Force.com has you covered! I used Force.com, some super simple HTML, a 15 dollar domain name registration from www.godaddy.com, and 15 minutes of my time and created a personal website (http://www.corycowgill.com). Its not real pretty at the moment, but the point of this is you can setup a site in 15 minutes. :)
Salesforce gives away free Force.com Licenses to anyone. These are production instances, NOT the developer edition instances you can also get for free. The Free Force.com edition gives you 1 GB of data, 100 Force.com user licenses, 250,000 page views, and some other goodies. You can sign up here to get your own free instance: https://www.salesforce.com/form/signup/freeforce-platform.jsp .
When you sign up for the Free Force.com edition, go ahead and setup your Force.com Site. You can follow this guide here: http://wiki.developerforce.com/index.php/An_Introduction_to_Force.com_Sites.
When you create a Force.com Site, it will provide you a URL like http://free-12415f14c3a-124e539428a-12dbf2f8eb2.force.com . Great, so we have a public website, but we don't have a very friendly name. No problem. Go to any DNS registrar, like GoDaddy, and you can register a domain name. Then use a CNAME to point to your Force.com Site. There is a guide here that lets you do that: http://developer.force.com/cookbook/recipe/registering-a-custom-domain-for-your-force-com-site .
This is another reason why I love working with the Force.com Platform. It makes your life super simple. You don't have to deal with Web Servers, Database setup, Email Services, Security setup, ETC. When you deploy a Force.com Site, you get the features of Salesforce.com like the Database, Secutity, Email Services, ETC.
Salesforce gives away free Force.com Licenses to anyone. These are production instances, NOT the developer edition instances you can also get for free. The Free Force.com edition gives you 1 GB of data, 100 Force.com user licenses, 250,000 page views, and some other goodies. You can sign up here to get your own free instance: https://www.salesforce.com/form/signup/freeforce-platform.jsp .
When you sign up for the Free Force.com edition, go ahead and setup your Force.com Site. You can follow this guide here: http://wiki.developerforce.com/index.php/An_Introduction_to_Force.com_Sites.
When you create a Force.com Site, it will provide you a URL like http://free-12415f14c3a-124e539428a-12dbf2f8eb2.force.com . Great, so we have a public website, but we don't have a very friendly name. No problem. Go to any DNS registrar, like GoDaddy, and you can register a domain name. Then use a CNAME to point to your Force.com Site. There is a guide here that lets you do that: http://developer.force.com/cookbook/recipe/registering-a-custom-domain-for-your-force-com-site .
This is another reason why I love working with the Force.com Platform. It makes your life super simple. You don't have to deal with Web Servers, Database setup, Email Services, Security setup, ETC. When you deploy a Force.com Site, you get the features of Salesforce.com like the Database, Secutity, Email Services, ETC.
Subscribe to:
Posts (Atom)