2

I have lightning components developed in our dev org. I want to put them in packaging org to package and distribute it(in test sandboxes first through beta managed package). Now as they have been developed in dev org that did not have a namespace, all dependencies, attribute types, controllers, event handlers etc , all are coded as per default case as mentioned in 1st part of this documentation:

https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/namespace_using_reference.htm

But now to package and distribute it, it is required that all should have namespace of packaging org as mentioned in 2nd part of documentation above. If I change the namespace, it won't work in dev org. So the question is how to dynamically assign namespace.

One approach I can think is copying all code in packaging org, and then changing all namespaces to new namespace, which would result in 2 copies of code. Don't know if that is correct approach.

I found some workarounds for field names refereed in JavaScript and labels used in JavaScript, but for other 12-13 aspects mentioned in above documentation, require a permanent approach. Or is it that for each of these, need to find out a new workaround(like using wrapper class for field names or maps for labels?)

As I read here , and if I am not wrong, lightning components should be developed in DE org WITH A NAMESPACE. So that means I would need to develop my components in packaging org itself?

  • Yes. You should develop in the dev org so you can use the namespace. Otherwise you are in for a rough go – Eric Feb 16 '17 at 5:54
  • 1
    What you need is Salesforce DX. You've probably missed the pilot, but in the next release or so you'll probably be able to use it (safe harbor, of course). – sfdcfox Feb 16 '17 at 5:58
  • @Eric : My Dev org has no namespace, but my packaging org has. So Do you mean to say that I should develop on packaging org? – Sarang Feb 16 '17 at 6:00
  • 1
    Yes sorry. In the org where the namespace is at. That's what it's there for. At least until DX – Eric Feb 16 '17 at 6:00
  • 1
    @Sarang Salesforce DX is designed with ISV development in mind. With it, you can have multiple development orgs that all share the same namespace. In the meantime, you'll need to your development in your packaging org. – sfdcfox Feb 16 '17 at 6:02
3

You can get away with the problem of namespace in your lightning components by crafting your own wrapper class structure for your data attributes.

The blog post here describes how to create message or wrapper class

https://medium.com/@mohitkumarsrivastav/transitioning-from-a-visualforce-developer-to-a-lightning-developer-c23c269157bf#.jviqi965l

So in short for every component that binds directly to the UI layer via attributes you will have your class structure to completely avoid namespace issues .

A simple wrapper class will look like below

public with sharing class TaskMsg {
 public TaskMsg() {
   this.isCompleted = false;
   this.istaskDue = false;
 }
 @AuraEnabled
 public String name {get;set;}
 @AuraEnabled
 public Date dueDate {get;set;}
 @AuraEnabled
 public String directions {get;set;}
 @AuraEnabled
 public String comments {get;set;}
 @AuraEnabled
 public Boolean isCompleted {get;set;}
 @AuraEnabled
 public String status {get;set;}
 @AuraEnabled
 public Integer noOfDaysSinceDue {get;set;}
 @AuraEnabled
 public Boolean istaskDue {get;set;}
 @AuraEnabled
 public String taskId {get;set;}
 @AuraEnabled
 public String sitePrefix {get;set;}
 @AuraEnabled
 public String URL {get;set;}
 @AuraEnabled
 public String templateId {get;set;}
}

Now the question on do we need to namespace the helper.js , component.cmp and controller.js ,please note we do not need any namespace explicitly specified for it to get it working .You can simply use c as default namespace and it will work .

If you are using lighnting out then in your Javascript code that sits inside your vf you might need a namespace but you can get it dynamically inside the vf from the apex .

  • Thanks for the answer Mohith. This approach is ok for handling namespace issues for fields, but other problems like mention of 'c' in handlers, labels(can be handled), dependencies, dynamic component creation etc remains. For that I guess we need to develop in same org where we are packaging. – Sarang Feb 16 '17 at 7:09
  • c works in namespace org as well.It's absolutely not needed to put namespace – Mohith Shrivastava Feb 16 '17 at 12:32
  • 1
    Could you include/summarize a bit of the relevant content here? – Adrian Larson Feb 16 '17 at 21:07
  • @AdrianLarson Done .Hope that makes it more clear – Mohith Shrivastava Feb 16 '17 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.