Sign Up ›

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Arun BalaArun Bala 

VF compilation behavior..

Folks,
I am in the process of migrating the visualforce pages from my DEV to other environments. In my VF page, I am referring to certain fields that are managed custom object fields. The actual field definition with the namespace prefix is : apPack__Account_c but in the VF page when I bind a inputField to the apPack__Account_c, upon compilation the code removes the prefix and makes it Account_c and hence the migration to other environments (without the namespace prefix) fail as expected.

This is already creating some butterflies in my stomach :-( ...


Anyone has a thought about this ?


Thanks.


Message Edited by Arun Bala on 12-31-2008 11:26 AM
ForcecodeForcecode
Have you installed the app with the namespace "apPack" into your dev org or has
your dev org the namespace "apPack" ?
 
If the namespace of your dev org is "apPack" you should create another dev org, install the managed app into this org and develop your VF pages in this org (like an extension to a managed package).
 
I think this should work and the namespace in the VF pages should not be removed upon saving.
Arun BalaArun Bala
Hi ForceCode,
Appreciate your quick response.

The Name space of the org. itself is apPack. Sorry I didnt mention that in my original post. Incidentally this is also the org for my development. Now I totally get your point. The only confusion I have is that the Apex Classes doesn't ignore the name spaces even though I created the Apex Classes on the source org. only but the fields on visualforce page does.




Message Edited by Arun Bala on 12-31-2008 12:30 PM

Message Edited by Arun Bala on 12-31-2008 01:02 PM
Arun BalaArun Bala
Any thoughts folks ? I am still figuring out whether I can do anything for this on the code because moving to another dev org (extension) will be a head ache ...
dchasmandchasman
The namespace defaulting should be relative to the namespace of the page itself and should not cause an issue in packaging/install provided that the page is also in the same namespace as the custom field you are referencing. The default namespace will then be fixed up during the installation process if you are using packaging. What technology are you using in your "migration" process: metadata api or packaging?
Arun BalaArun Bala
Hi Doug,
Thanks for your response. You're right. The page is also in the same namespace as the custom field. But as you had righty said, I am using Meta data API (ant scripts) to migrate the code. I am not adding my VF page to the source package.

So the ant build fails for the VF pages because of the absence of the namespace prefix.


Thanks.
Arun BalaArun Bala
Doug - do you think there is a work around for this on meta data API based migration methodology ?



Thanks.
Arun BalaArun Bala
Folks,
Just wanted to check if at all anyone has a different approach to solve this issue. Thanks in advance.
dchasmandchasman
I sent an email on this to the lead dev for the metadata api asking for him to comment.
Arun BalaArun Bala
Thanks Doug. I appreciate your help.
Bill EidsonBill Eidson
  Arun -

  I've sent a private message w/ contact info so we can discuss this quickly.
One thing, though, I've read through the posts above, and want to confirm the scenario; is this correct? If not, let me know where I'm off:

- The DE org (with the visualforce page in question) has a namespace prefix set.
- The desired target org does contain custom fields having the DE org's namespace prefix (from a package install).
- You're attempting to move the page from the DE org (where it will have a namespace) to the target org (where it won't, unless it is installed using packaging) -- is there a reason for not using a package upgrade to install the visual force page.

  Thanks,

  - Bill
Arun BalaArun Bala
Hi Bill,
Thanks for your response. Your interpretation of the problem is absolutely correct. I will also contact you offline.


Thanks again.
Bill EidsonBill Eidson

  The issue is that the visualforce page was referencing components (custom fields) within the same managed package, but attempting to install the page outside of packaging (for testing purposes) means that the page will be without a namespace, and therefore require fully qualified custom field references; the described behavior is as expected.
  I spoke with Arun, and it sounds like they can still use packaging to upload/install/test unlisted versions of their application.

  Thanks,

  - Bill