Sign Up ›

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
ForcecodeForcecode 

Error: Cannot use Apex Attribute var (in component mynamespace:mycomponent) without Global access...

We have a VF component in our managed package that our customers should use in their org.
 
Access is set to "global" in the component and the we use the tag componentbody so that our customers are able to generate custom iterations.
 
When I create a new VF email template and include the component, I get the error:
 
>>Error: Cannot use Apex Attribute var (in component myNamespace:myComponent) without Global access in a component/page that is not in the same namespace of the component<<
 
The component is set to "global, why is this error thrown ?
 
 Is there some more information available what is possible  with components in managed packages ?
 
Why is the "global" designation for a component deprecated as described in the VF docs ? Is there any alternative ?
 
The components are a flexible way to allow our customers to customize our app but they are usesless in a managed package when there are so many restrictions.
 
ForcecodeForcecode

Ok I found it, I had to add access="global" not only to the component but to the attribute as well.

What I still not understand, what are the plans for components in managed packages ?

From the docs:

>>NOTE: Components with this designation are subject to the deprecation policies as describes for managed packages<<

Where is this described? Will it not work in future release ? What are the alternatives ?

Would be great if someone clarifies on this.
dchasmandchasman
I've pinged my team's tech writer to find out more about the location of this information but the basic idea is that once you mark something as global (class, component, component attribute, etc) and package it you can never remove it (same rules we have in apex code). This is an attempt to guarantee that as a publisher you cannot break existing consumers of your components by removing an attribute or adding a new required attribute etc - if you change the semantics or valid values etc for an attribute you can still break your existing consumers.

BTW if you are using packaging as a mechanism to move objects from a dev or test org to production there is a more appropriate technology (deploy using ant deploy or the eclipse force.com plugin) that does not introduce the managed package constraints - I suspect this might be something that you'll want to consider.
ForcecodeForcecode
Thanks for the info Doug, I can live with that.
 
We use a managed package to support the Professional Edition and the PE users can now use and customize our components even in this edition.