Supposons que la propriété list soit déclarée comme telle dans votre contrôleur: Public List<Beer__c> ColdOnes { get; set; }
. Bien dans Visualforce, vous référencez les bières par leur nom de propriété dans le contrôleur ... {!ColdOnes}
. Ce qui suit est la plupart du temps pris du guide Visualforce, mais j'ai adapté pour répondre à notre sujet thist trempe :)
<apex:dataTable value="{!ColdOnes}" var="co" id="theTable" rowClasses="odd,even" styleClass="tableClass">
<apex:facet name="caption">table caption</apex:facet>
<apex:facet name="header">table header</apex:facet>
<apex:facet name="footer">table footer</apex:facet>
<apex:column>
<apex:facet name="header">Beer Name</apex:facet>
<apex:facet name="footer">column footer</apex:facet>
<apex:outputText value="{!co.name}"/>
</apex:column>
<apex:column>
<apex:facet name="header">Alcohol Volume</apex:facet>
<apex:facet name="footer">column footer</apex:facet>
<apex:outputText value="{!co.alcohol_volume__c}"/>
</apex:column>
</apex:dataTable>
Sachez simplement que si vous définissez ColdOnes avec une valeur recherchée dans votre code, vous besoin de sélectionner les champs que vous avez l'intention de produire dans votre Visualforce. Donc:
ColdOnes=[select name, alcohol_volume__c from Beer__c where blahblahblah];
Eh bien, je pars pour une pinte. J'espère que cela pourra aider!
Oh, attendez, voulez-vous dire que la liste contient des sObjects? Maintenant, c'est une question différente ... Que diriez-vous d'utiliser sObject plutôt que d'utiliser un objet personnalisé "attrape-tout" avec les champs communs entre les différents objets, de faire une liste des objets personnalisés, puis de sObject liste comme une liste de l'objet personnalisé en question? Je veux dire, je ne l'ai jamais essayé, mais ça devrait fonctionner en théorie ... (Quoi qu'il en soit, je pars cette fois, la bière) – Aaron
Correct, sObjects. J'ai utilisé cette idée d'objet personnalisé «fourre-tout» comme vous l'avez mentionné, mais nous avons des problèmes avec un client. Ils rencontrent des problèmes où seul l'utilisateur installateur peut créer l'objet personnalisé dans le package géré. J'espérais que l'utilisation de sObject à sa place atténuerait le problème. – CDelaney
Je suppose que le contrôleur est un avec la classe de partage alors? Sur quelle édition se trouve votre client? S'ils sont sur Enterprise ou Unlimited, ils peuvent simplement définir des cruds pour l'objet personnalisé et ses champs par profil. Si elles sont sur Professional, je pense que vous devrez trouver une solution de contournement. En supposant que la réponse est oui à la question 'avec partage', essayez de rendre statique les propriétés/méthodes concernées. Comme les statistiques sont initialisées avant la création de la classe, vous devriez être capable de contourner les problèmes de crud à condition que cela soit évolutif pour le reste de votre code. – Aaron