If you're brand new to Lightning on the Salesforce1 Platform, and you're having a bit of trouble following the cool but relatively complex Expenses sample app from the Lightning Components Developer's Guide, maybe this Lightning-to-Lead tutorial will work better for you.
The goal is simple: Create a one-page app that basically does what Web-to-Lead does, which is to create a new Lead record. Nothing glorious, but it's just complicated enough to go over some core concepts. When you're done, you'll end up with a simple page with a few fields and a lone button.
Sound simple? Give it a try and let me know what you think!
Insights and lessons learned from designing and implementing cloud solutions on the Salesforce1 Platform. Side adventures into Heroku with Ruby on Rails apps also included.
Friday, October 31, 2014
Friday, October 24, 2014
Share Chatter files across communities... or not
"One version of the truth" is the holy grail in content management. Chatter Files is salesforce.com's solution for allowing users to manage document revisions in Salesforce, while making sure that links to the file always give people the latest version. But with Communities, "one version of the truth" becomes more difficult to achieve.
Take the following scenario:
As it stands in Winter '15, files created or uploaded to one community, internal or external, can only be shared within that same community in Chatter. So, to share a file across communities, users effectively have to recreate a duplicate instance of the file by uploading it again as a new file to the new community.
The only way that files can be shared or seen across communities is to create a Salesforce CRM Content library that's shared with users who have access to multiple communities. But even then, users will not be able to attach the file to a Chatter post. They'll be able to find the file in Global Search, and share URL links to the file, but unfortunately "native" Chatter file attachments will not be possible.
If this limitation with file sharing across communities affects or bothers you, please promote the idea, "Sharing Files from Chatter to Communities".
Take the following scenario:
- John Doe collaborates with internal users to create a pitch deck for a new product.
- John uploads the file to the Competitive Advantage Chatter group in his org's internal community.
- Several iterations later, the deck is ready to be shared in his company's partner community, called AllianceNet.
- John uses the Global Header to switch from his org's internal community to the AllianceNet community.
- John goes to the All AllianceNet group to share the file, already stored in Chatter, with the group, but... where's the file?
As it stands in Winter '15, files created or uploaded to one community, internal or external, can only be shared within that same community in Chatter. So, to share a file across communities, users effectively have to recreate a duplicate instance of the file by uploading it again as a new file to the new community.
The only way that files can be shared or seen across communities is to create a Salesforce CRM Content library that's shared with users who have access to multiple communities. But even then, users will not be able to attach the file to a Chatter post. They'll be able to find the file in Global Search, and share URL links to the file, but unfortunately "native" Chatter file attachments will not be possible.
If this limitation with file sharing across communities affects or bothers you, please promote the idea, "Sharing Files from Chatter to Communities".
Friday, October 10, 2014
Invalid apex:attribute name values
The apex:attribute component in Visualforce allows developers to pass custom Apex class instances as attributes from the parent component or page to the child component. In this manner, it's possible to pass a page controller itself as an attribute to a component on the page, using a simple self property like the following.
What the documentation doesn't say is that apparently (at least in Winter '15, API 32.0) there are keywords to avoid when naming your attribute, even though the Visualforce parser will not tell you there's a problem.
Trying to name your attribute "controller" will cause something like the following error to appear when saving a page: Wrong type for attribute <c:buggersitepaypalcheckout controller="{!self}">. Expected BuggerSiteSimpleSelfRegController, found String
Trying to name your attribute "parent" will cause a completely blank error message to appear when saving a page. But it's an error that will prevent you from saving your page, nonetheless.
Do you know any other hidden no-no's with naming apex:attribute elements? Please share so that we can all avoid these frustrating quirks int he future.
public CustomController getSelf() { return this; }
What the documentation doesn't say is that apparently (at least in Winter '15, API 32.0) there are keywords to avoid when naming your attribute, even though the Visualforce parser will not tell you there's a problem.
Trying to name your attribute "controller" will cause something like the following error to appear when saving a page: Wrong type for attribute <c:buggersitepaypalcheckout controller="{!self}">. Expected BuggerSiteSimpleSelfRegController, found String
Trying to name your attribute "parent" will cause a completely blank error message to appear when saving a page. But it's an error that will prevent you from saving your page, nonetheless.
Do you know any other hidden no-no's with naming apex:attribute elements? Please share so that we can all avoid these frustrating quirks int he future.
Labels:
bug,
component,
Salesforce,
technical support,
Visualforce
Subscribe to:
Posts (Atom)