function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Ken KoellnerKen Koellner 

Creating a name space for production (and sandbox) org?

I'm starting to work through the Lightning Components Developer Guide working my own developer org where I've created a name space.

But I'm confused about how to do this in our real development stream.  We have a production org and some sandboxes we do development in.  (We develop in sandboxes instead of individual developer orgs as we need common data that is setup for all developers and there's no way we could maintain it in several individual developer's org.)

In out production org and in our sandboxes, there is no "Edit" button to allow specification of Namespace on the Packages page.

So I'm unclear how to reserve a namespace.  Any clue? 

We do have a domain name registered.  Does it have something to do with that?
ShashankShashank (Salesforce Developers) 
Namespaces cannot be created in sandboxes or production orgs. You can create only unmanaged packages in those orgs. You can probably try developing your code and custoizations in any sandbox and use the ANT migration tool to migrate the changes to a developer org in which you can create a namespace.

There is an idea around sandboxes for developer edition orgs: https://success.salesforce.com/ideaView?id=08730000000ZgI6AAK
Ken KoellnerKen Koellner
I'm not sure what the implication are with respect to development for Lightning then. 

The example in the guide uses namepace. 

Is namespace required? 

If so, will ALL development for Lightning have to begin in a developer's org (instead of a sandbox) and then get migrated? 

Once it is migrated, can it be edited in a sandbox org?
Ken KoellnerKen Koellner
Another issue would be, suppose we want to reserve one namespace for all our Lightning projects, but we have several developers each working in their own dev org.  Can multiple dev orgs all access the same namespace?  The instructions for creating a namespace suggested it has to be unique to an org.  So how can multiple developers work in one namespace?
 
ShashankShashank (Salesforce Developers) 
This FAQ should answer your questions (look for "namespace questions"): https://developer.salesforce.com/page/Lightning_FAQ

According to it, namespace for lightning components is mandatory only for now, in the "beta" stage. It will not be the case when lightning components are "Generally Available".
Alan ChapmanAlan Chapman
I'm failing to see the point of including the "Lightning Components BETA" in production developer/pro sandbox orgs (like the Unlimited Edition) if you cannot even add this required namespace needed to access the tools to develop components in the Console. Sorry, I'm also not following this migration strategy you presented either:

"You can probably try developing your code and custoizations in any sandbox and use the ANT migration tool to migrate the changes to a developer org in which you can create a namespace."

This doesn't seem to make sense. The point of this thread is we can't develop our code and customizations in any sandbox because the "File > New > Lightning Application" and related tools aren't available in our sandboxes. My dilemma is I have some custom Apex classes and objects in my sandbox that I need access to while developing my lightning components. Playing with toy apps in a free Developer Edition is going to do absolutely nothing for me. Is there a solution to this? Or is the answer "Wait for it to not be in beta" because I have product owners wanting me to develop for Salesforce 1 using Lightning, and we were under the impression that we could use it.
jjasondavisjjasondavis
For those in the same boat, using their own sandbox or production org, you can use the default namespace which is c.  See more here https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/namespaces_using_default.htm