Hi, Sebastian,
Are you trying to override the tab for the alas1__Ramo__c object? The object whose tab you are overriding has to match the standardController object in your Visualforce code.
Emily
The issue here has to do with the Managed Packages. Here’s the deal:
From your org that has the “labs01” namespace, to override the Tab action for an object included in the “alas1” Managed Package, you have to NOT specify a Standard Controller. Rather, change the redirect override syntax to be:
<apex:page controller=“skuid.Redirects” action=“{!redirect}?page=RamoTab”/>
Moreover, you will not be able to override actions of any other type for objects in the “alas1” managed package, from the “labs01” org. This is a very annoying restriction that Salesforce has in place for overrides, preventing you from overriding actions of objects that come in managed packages.
You’re correct. That is what I’m trying to do. The object name is alas1__Ramo__c as in the VF code.
Thanks Zach. The VF page is now listed and can be selected as an override for the alas1__Ramo__c object tab.
There’s still an error when rendering the page:
You’ve been INKED! (Something went wrong)
Skuid was unable to redirect the user to standard Salesforce Page Layouts, and no Skuid Page could be used instead.
And by
you will not be able to override actions of any other type for objects in the “alas1”
What other actions do you mean? So far I have accomplished to override New, Edit and View actions in the same alas1__Ramo__c object.
Furher notes:
The whole scenario is this: we have a Salesforce app to be distributed through Trialforce only. We have a developer org and a packaging org. Since we are testing Skuid to see how it fits our goals, I used an old org (the one with the “labs01” namespace) to install Skuid and our managed package to test it out; but I’m starting to believe it would be better if we test it in a clean org (no namespaces) and deploy our app through ant from our developer org (no alas1 namespace either).
Will this be a better environment for our purposes?
Try either (a) swapping the ?page= for an &page= in the override, like this:
<apex:page controller=“skuid.Redirects” action=“{!redirect}&page=RamoTab”/>
or using the Skuid Page component approach:
<apex:page readonly=“true” doctype=“html-5.0”>
<skuid:page page=“RamoTab”/>
</apex:page>
Regarding your scenario, I’d avoid the hassle of setting up a fresh org, you should be able to test out Skuid pretty well using your current approach, and if you decide to make the jump and have your core managed package depend on Skuid, then at that point you can move your override VF pages into your packaging org.
The ampersand worked well.
Thanks for sharing your opinion as well. So the namespace “labs01” shouldn’t interfere with our testing? I thought the source of this issue I’m posting was the namespaces.
The only part of your testing it will interfere with is in creating Visualforce override pages, which is not necessary to do if you’re justing testing out the functionality of Skuid, in my opinion.
I know this is old but to tie up what Zach was saying with how this ended is that, in the DE org it looks like you might be able to do multiple overrides, but once the package is installed it looks like Zach’s comment about not being able to do multiple will apply.
Implemented! Let me know how it looks… I tried to be as straightforward as possible (thank you, Zach) The main change is the section Special considerations for managed packages.
Can page assignments still be used?
Yes! There are so many permutations! On that bright shiny future day when we overhaul documentation, this will be presented in a better manner. In the mean-time, I’m adding it to that tutorial.
For now, the best tutorials for page overrides (in terms of getting a broad scope of what you can do) are the overview/ cheat sheet and the one on the skuid:page component one (you may have already realized this).
