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
MrTheTylerMrTheTyler 

Adding the Salesforce Standard "View" elements to my Custom Tab

I'm overriding the default tab view for the Case object.  It's all easy enough to add access to existing views via a dropdown, just like the default tab would have

 

 

      <apex:selectList value="{!filterId}" size="1">
        <apex:actionSupport event="onchange" rerender="list"/>
        <apex:selectOptions value="{!listviewoptions}"/>
      </apex:selectList>

 

 

But of course an overriden tab should provide the preexisting functionality which enables the user to create new views, edit existing ones, etc.  So is there a way I can leverage salesforce's code to provide the standard view links like below (Create New View | Edit | Delete | Refresh) in my custom visual force page?

 

 

 

Cheers,

 

Tyler

 

Bhawani SharmaBhawani Sharma

Hi Tyler,

 

You can use the following code :

 

<apex:selectList value="{!FilterID}" size="1">
                <apex:selectOptions value="{!standardSetController.listViewOptions}"/>
                <apex:actionSupport event="onchange" reRender="pbs,navigationPanel" status="loadingStatus"/>
            </apex:selectList>
            <apex:outputLink value="/ui/list/FilterEditPage?ftype=a&retURL={!$CurrentPage.URL}" id="newLinl">Create New View</apex:outputLink>
            &nbsp;|&nbsp;
            <apex:outputLink value="/ui/list/FilterEditPage?id={!FilterId}&retURL={!$CurrentPage.URL}" id="editlink">Edit</apex:outputLink>

 

Hope this will help.           
maxout2maxout2

That is I am for too. Thanks.

 

What about the hot list at the right hand side:

<select  id="hotlist_mode" name="hotlist_mode" onchange="submit();" title="Display Selection">
<option value="2">Recently Created</option>
<option value="1">Recently Modified</option>
<option value="3" selected="selected">Recently Viewed</option>
</select>

 
JayHHJayHH

I am looking for a similar solution, but more generalized. The given answer only appears to work completely for the Account object. The "edit" link works fine in any context, but the "create new view" link as written always goes to the Account view page, driven by the 'ftype=a' parameter.

 

For standard objects, it appears you can hard-code the ftype value. 'Account' is type 'a', 'Contact' is type 'c', 'Case' is type 't', etc.

 

For custom objects that argument looks like a standard generated ID, e.g.

 

/ui/list/FilterEditPage?ftype=01IK00000000JC4&retURL=...

 

I can't see any correlation between this ID and the instance object IDs, so I assume it is an entry in some meta-data table. As such, I assume it can also vary from org to org, so when developing a page for an app, how do you programmatically determine the ftype for your custom object so you can create the "create new view" link?

 

Thanks in advance,

 

Jay
cignuscignus

did you find an answer to this question? I am really stuck with same probelm

 

Behzad
JayHHJayHH

Yes we did, though it's a bit of a "hack," and may be unstable if SF decides to change the elements of their enhanced list.

 

I'm sorry I can't share actual code samples, but the basic logic is:

  1. Load an enhanced list using regular force.com tags. This list will contain the SF-generated filter list for the current object type. Use a DOM navigator to find the View select/option tags. Determine a selector expression you could use to query for those.
  2. Upon the document ready event, launch a Javascript function with a small delay using setTimeout(). 10 ms seems to be enough, but a bit longer may be safer.
  3. In that function, use jQuery or other javascript library to execute your selector expression and pull the View drop-down elements from the generated enhanced list. Re-use the display names and links in your own select. Style as you like.
  4. Use CSS style entries to hide the original SF-provided enhanced list in the final version.

The reason for the delay in step 2 is that the enhanced list itself appears to be Javascript/Ajax generated. The tag on the server side only generates the basic div and the code to call the Javascript. You have to give some time for the built-in SF Javascript functions to run before the enhanced list will be accessible in the DOM.

 

As I mentioned - this is a fragile solution. SF could potentially change the structure of the enhanced list in the future, breaking whatever selectors you use to query for the View drop-down. It's the only solution we were able to come up with, however. 

 

Hope this helps!

 

 
cignuscignus

Thanks Jay

 

This will solve the problem. I thought of this solution but I was seeking a less messy solution.

 

Cheers