function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
gregsgregs 

customization of managed package visualforce pages

Does anyone know of any way for a developer to provide a managed visualforce page inside a managed package that customers can override with their own visualforce page layout and/or controller logic? The use case is we have an out of the box visualforce page in our managed package that users want to customize to add their own custom fields the as well as add some logic to the page that pre-populates some of the fields when it is loaded based on some logic. While this could easily be done with s-controls or unmanaged code, is there a way to do this using managed code?
Best Answer chosen by Admin (Salesforce Developers) 
mtbclimbermtbclimber

When a button/link/action is overridden with a Visualforce page in a managed package the customer can override it with their own page or get back to the standard salesforce.com  page if they so choose. The override setting is "subscriber controlled" if you are familiar with that term.

 

The best strategy available today to allow the subscriber to leverage Visualforce/Apex from a managed package while augmenting with their own customizations (fields, etc.) is to factor your solution like this:

 

1) Utilize a standardcontroller in your page <- this will allow a clone of your page to accommodate the subscriber's goals and will keep them in Visualforce (and out of Apex) for the majority of their customization needs.

2) Break up your Visualforce page into components that you mark as global (along with appropriate attributes)

3) Mark any extension classes and/or structs as global so your subscriber can use them as necessary

4) Optionally annotate a section of your page that isn't rendered with "insert custom fields here" instructions.

 

Now, when the subscriber wants to add their fields to a page from a managed package their flow would be:

 

1) Clone your page (including refs to your global, custom components and apex standard controller extensions)

2) Augment their cloned variation with the requisite input/outputfields for their custom fields in the location/s you may have suggested.

3) Save

4) Override the respective action with their new page.

 

With this solution your customer will continue to receive the benefits of fixes/enhancements to your custom components and logic (apex controller extension) and can add custom fields to a packaged interface.

 

We're looking at some features for this year that would move more of the burden to the package author (and easier for the subscriber) but this approach will always be available and more importantly is so today.

 

Hope that helps.

All Answers

mtbclimbermtbclimber

When a button/link/action is overridden with a Visualforce page in a managed package the customer can override it with their own page or get back to the standard salesforce.com  page if they so choose. The override setting is "subscriber controlled" if you are familiar with that term.

 

The best strategy available today to allow the subscriber to leverage Visualforce/Apex from a managed package while augmenting with their own customizations (fields, etc.) is to factor your solution like this:

 

1) Utilize a standardcontroller in your page <- this will allow a clone of your page to accommodate the subscriber's goals and will keep them in Visualforce (and out of Apex) for the majority of their customization needs.

2) Break up your Visualforce page into components that you mark as global (along with appropriate attributes)

3) Mark any extension classes and/or structs as global so your subscriber can use them as necessary

4) Optionally annotate a section of your page that isn't rendered with "insert custom fields here" instructions.

 

Now, when the subscriber wants to add their fields to a page from a managed package their flow would be:

 

1) Clone your page (including refs to your global, custom components and apex standard controller extensions)

2) Augment their cloned variation with the requisite input/outputfields for their custom fields in the location/s you may have suggested.

3) Save

4) Override the respective action with their new page.

 

With this solution your customer will continue to receive the benefits of fixes/enhancements to your custom components and logic (apex controller extension) and can add custom fields to a packaged interface.

 

We're looking at some features for this year that would move more of the burden to the package author (and easier for the subscriber) but this approach will always be available and more importantly is so today.

 

Hope that helps.

This was selected as the best answer
gregsgregs

Thanks very much.  That was the approach we used and it worked perfectly.

Now I have a follow up question to this original question.  We currently have an unmanaged package deployed in a large customer's org that uses virtual base class design and inheritance so the customer can override functionality as needed by overriding the base classes.  This works because they have visibility into the unmanaged code base and can write unmanaged code to extend this functionality, even modifying our base class design if they wanted.

 

This was originally deployed this way long ago as an unmanaged package to this customer because were were not able to create a managed package using this class override mechanism at the time that could have some of the base code instantiate an overriden class at run time from the name of the class alone.  In other words, reflection is not supported so there is no way to know at runtime what the name of the overridden class is that the base code in the managed package should call.

 

We now want to make this package managed and release it to this customer as well as other new customers so we can manage it and push upgrades to them as needed when our base product changes, and keep the source code hidden from them as well.  What is the best way to go about this from an architectural point?  Can/should we keep all existing base classes as global virtual with all methods and fields we want customers to be able to access defined as global as well?  Will we be able to support this once it becomes a managed release package?  Or can you recommend another design approach that uses a mechanism other than having customers override classes with the new functionality they want?

 

Thanks

mtbclimbermtbclimber

Check out dynamic binding and fieldsets in the Spring '11 release as it may offer an alternative approach depending on your requirements:

 

http://developer.force.com/releases/release/Spring11/Visualforce+Dynamic+Binding

http://www.youtube.com/watch?v=k8X3jojSQnQ

 

 

gregsgregs

That is a great feature!  especially for admins!  However, our customer requirements include the ability to customize our managed package with somewhat complex logic written in apex and vf pages,  Most of the time these customizations are much more than just adding and choosing fields to display.  They typically involve invoking a process in the managed package (via an api call conaining the id and name of an object), the engine in our managed package does some base functions, and then calls their overridden code which typically does some more querying on some objects in their org and includes fields from these objects in pages they display or information they return back to the managed package to continue processing.  They do this today by overriding base classes but we need another way to do this in the absence of reflection.  Is there an approach you can recommend using overriden classes and global methods or do we need another way?

sushmaraosushmarao

 

 

Break up your Visualforce page into components that you mark as global (along with appropriate attributes).

Can you please guide me how to make the components global.

 

 

Sushma_RaoSushma_Rao

 

I was able to create global components, but i am not able to reference the components from the managed package on to the page.

Please help.

 

Thanks in advance.

Manu206Manu206

This topic is almost 3 years old..

Is there any other solution so far to handle customization of visualforce pages?

mysteriousauramysteriousaura
any new thoughts on this topic?