I have to be able to display, from a custom Object, specific fields.

For example, if the field name contains "_network", I want only to display those fields.

Since at work they will be keeping in creating new fields "_network", I need a system in visualforce that allows me to dynamically display the fields (apex:inputfield) with the constrains described above.

Is this possible by only using visualforce and a controller?

  • 1
    Yes.Possible through VF page and Controller – Samir Mar 8 '17 at 16:30
  • Thank for your answer. Do you happen to have any link reference? – Cuban coffee Mar 8 '17 at 16:32
  • 1
    Can you please elaborate a little more? Current requirements are kinda unclear. – Mahmood Mar 8 '17 at 16:39
  • Hi Mahmood, on a visualforce page I want to place the tag "apex:inputfield". The number of "apex:inputfield"'s are unknown, maybe 5 or 6. So I need a system to dynamically place those tags in visualforce. – Cuban coffee Mar 8 '17 at 16:45

One way is for the controller to provide a list of the field API names (that the controller will also have to query):

public String fields {
    get {
        // Hard coded list here: build your varying list instead
        return new String[] {'Name', 'Birthdate'};

public Contact contact {...}

and then use this syntax to reference the relevant SObject fields by the API names:

<apex:repeat value="{!fields}" var ="f">
     <apex:inputField value="{!contact[f]}"/>

This is the exact use case for Field Set. You don't even need Apex, it is 100% configurable. The example from the docs will work equally well with <apex:inputField> as with <apex:outputField>:

<apex:page standardController="Contact">
    <apex:repeat value="{!$ObjectType.Contact.FieldSets.properNames}" var="f"> 
        <apex:outputText value="{!Contact[f]}" /><br/>

If you really want these fields in Apex as well, that is of course supported, though in this case I would not follow the example in the docs. Regardless, you can loop through the FieldSetMember instances and do whatever you wish with them. For example:

List<String> fields = new List<String>();
FieldSet properFields = SObjectType.Contacts.FieldSets.properNames;
for (FieldSetMember member : properFields.getFields())
  • Biggest problem with field sets is that someone has to remember to add the new fields to the fieldset. When delivering to clients I always try to minimize the amount of "Remembering how" they have to do so often go with the code route. I dread the call a year later asking how they add a field to the page. By that time I have forgot how to do it as well lol – Eric Mar 8 '17 at 17:49
  • 1
    @Eric Yeah but not needing to deploy changes to code is a big win in my book. At the end, Field Sets empower your admins more than code. It's up to you to share the keys. You can use Custom Settings instead, but they have the same basic pros/cons and are not tailor made for this purpose. – Adrian Larson Mar 8 '17 at 17:51
  • Agree with the code changes part. Thats is part of my criteria as well when implementing that it has to work without more deployments. In this example adding a field with the _network in the name would not require a code change or a fieldset update. Simply adding the field to the object and it would magically appear...This is what is great and not great about the platform. – Eric Mar 8 '17 at 17:54
  • Well it's a trade-off of creativity vs. simplicity. You could certainly write a List Custom Setting that contains field substrings, then pull any matches from the describe field map. I would rather share the simpler route for the developer in this case, knowing nothing about their skills nor their admin's. – Adrian Larson Mar 8 '17 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.