Bonjour,
Personnellement, je préfère la première car cela représente un cas particulier d'affichage et cela permet de ne pas polluer le modèle de données avec des problématiques d'affichage. Je suis d'accord, il serait en effet dommage de devoir modifier le modèle pour régler un problème de page web. Je ne vois pas par contre comment régler le problème d'itération sur List<AbstractModel> sans rajouter une interface commune. Mais c'est un moindre mal si cela nous permet de garder le modèle intact.
Par contre, je pense qu'elle ne convient pas exactement au problème, car l'objet à manipuler devrait être un javaBean car wicket affiche un propriété d'un bean, par exemple: columns.add(new PropertyColumn<Molecule>(new Model<String>(getString("Molecule.nomCommun")), "nomCommun", "nomCommun")); il va appeler la méthode getNomCommun() de la ligne courant. Il suffit de ne pas utiliser PropertyColumn et de créer à la place une classe interne anonyme qui hérite d'AbstractColumn<Molecule>. Exemple :
column.add(new AbstractColumn<Molecule>(new Model<String>(getString("Molecule.nomCommun"))) { @Override public void populateItem(Item<ICellPopulator<Molecule>> item, String componentId, IModel<Molecule> rowModel) { item.add(new Label(componentId, RowMoleculeFinder.getNomCommun(rowModel.getObject())); } });
ou mieux encore : garder PropertyColumn<Molecule> mais utiliser la stratégie de surchage non pour trouver la valeur mais le nom de propriété. Ainsi pour continuer avec l'exemple du nom commun, la méthode RowMoleculeFinder.getNomCommunProperty(Molecule molecule) rendrait "nomCommun", tandis que RowMoleculeFinder.getNomCommunProperty(MoleculeProvenance moleculeProvenance) rendrait "molecule.nomCommun". Par ailleurs, je viens de remarquer que vous étendez systématiquement dans cette page une PropertyColumn (ou ces dérivés tel DecimalPropertyColum, ...) au lieu d'AbstractColumn (les propriétés déclarées dans le constructeurs n'étant ensuite pas utilisées).
Nous allons également essayer de réfléchir à une solution.
Pour revenir a la même problématique pour les Produit, les molécules portant sur les produits, cela devient également lorsque l'on doit afficher le nom du programme sachant que: * la ligne est soit une Molecule, soit une MoleculeProvenance * le produit est soit une Fraction, soit un extrait
Par exemple, pour la référence du lot, je dois faire deux cas encore suivant le type de produit: * "produit.purification.lotSource.ref" * "produit.extraction.lot.ref" Dans ce cas particulier où on doit afficher " - " (valeur nulle) quand c'est une Molecule, et la valeur de deux propriétés différentes (suivant si c'est une Fraction ou un Extrait) quand c'est une MoleculeProvenance, je conseillerais également d'utiliser la solution de surcharge pour obtenir la bonne propriété. Les méthodes aurait alors deux arguments comme par exemple : RowMoleculeFinder.getProgrammeProperty(Molecule, Fraction) (au total 4 surcharges pour chacun des cas).
Puisque Wicket est écrit intelligemment, cette solution devrait marcher même pour les deux surcharges avec Molecule. En effet, dans le PropertyResolver de Wicket nous avons :
/** * Looks up the value from the object with the given expression. If the expression, the object * itself or one property evaluates to null then a null will be returned. * * @param expression * The expression string with the property to be lookup. * @param object * The object which is evaluated. * @return The value that is evaluated. Null something in the expression evaluated to null. */ public final static Object getValue(final String expression, final Object object) Ainsi les deux surcharges utilisant Molecule peuvent rendre la valeur null et le résultat de l'évaluation du PropertyColumn rendra bien null. Il suffit alors de rajouter le behavior RemplaceEmptyLabelBehavior sur le cellItem du populateItem pour obtenir la chaîne désirée pour ces cas.
Adrien -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789