Utiliser une classe commune pour la génération des beans (a.k.a org.jdesktop.beans.AbstractSerializableBean)
Hello, Dans la génération des beans (avec utilisation des pcs) on génère toutjours le même code: <pre> protected final PropertyChangeSupport pcs = new PropertyChangeSupport(this); ... public void addPropertyChangeListener(PropertyChangeListener listener) { pcs.addPropertyChangeListener(listener); } public void addPropertyChangeListener(String propertyName, PropertyChangeListener listener) { pcs.addPropertyChangeListener(propertyName, listener); } public void removePropertyChangeListener(PropertyChangeListener listener) { pcs.removePropertyChangeListener(listener); } public void removePropertyChangeListener(String propertyName, PropertyChangeListener listener) { pcs.removePropertyChangeListener(propertyName, listener); } protected void firePropertyChange(String propertyName, Object oldValue, Object newValue) { pcs.firePropertyChange(propertyName, oldValue, newValue); } protected void firePropertyChange(String propertyName, Object newValue) { firePropertyChange(propertyName, null, newValue); } </pre> Il se trouve qu'il existe une classe aussi qui fait déjà ça dans swingx-common. Je voudrais qu'on se base sur cette classe plutôt que de la générer à chaque fois (et en moins bien) Pro: - déjà existant - gère bien la sérialization alors que nous non - gère les voteable pas nous Cons: - c'est une dépendance normalement plutôt réserver aux ui mais bon celle-ci est bien neutre (mais y' a aucune dep et juste moins de 10 classes) (donc pas vraiment contre :)) - on dépend à la génération d'une classe externe (donc on est pas maitre à 100% du code généré). Si personne n'est contre je le ferais cette semaine pour la version que je vais releaser d'eugene mercredi (pour masc) -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
On Sun, 28 Oct 2012 13:11:52 +0100 Tony Chemit <chemit@codelutin.com> wrote:
Hello,
Dans la génération des beans (avec utilisation des pcs) on génère toutjours le même code:
<pre>
protected final PropertyChangeSupport pcs = new PropertyChangeSupport(this);
...
public void addPropertyChangeListener(PropertyChangeListener listener) { pcs.addPropertyChangeListener(listener); }
public void addPropertyChangeListener(String propertyName, PropertyChangeListener listener) { pcs.addPropertyChangeListener(propertyName, listener); }
public void removePropertyChangeListener(PropertyChangeListener listener) { pcs.removePropertyChangeListener(listener); }
public void removePropertyChangeListener(String propertyName, PropertyChangeListener listener) { pcs.removePropertyChangeListener(propertyName, listener); }
protected void firePropertyChange(String propertyName, Object oldValue, Object newValue) { pcs.firePropertyChange(propertyName, oldValue, newValue); }
protected void firePropertyChange(String propertyName, Object newValue) { firePropertyChange(propertyName, null, newValue); } </pre>
Il se trouve qu'il existe une classe aussi qui fait déjà ça dans swingx-common.
Je voudrais qu'on se base sur cette classe plutôt que de la générer à chaque fois (et en moins bien)
Pro:
- déjà existant - gère bien la sérialization alors que nous non - gère les voteable pas nous
Cons:
- c'est une dépendance normalement plutôt réserver aux ui mais bon celle-ci est bien neutre (mais y' a aucune dep et juste moins de 10 classes) (donc pas vraiment contre :)) - on dépend à la génération d'une classe externe (donc on est pas maitre à 100% du code généré).
Si personne n'est contre je le ferais cette semaine pour la version que je vais releaser d'eugene mercredi (pour masc)
Bon au final, j'ai ajouté une tag-value qui permet de spécifier une super-classes aux bean généré et si tel est le cas la super-classes doit implanter toutes les méthodes générées communes, cela résoud le problèmes sans forcer aucune inclusion d'une autre lib dans la génération d'eugene ce qui est le mieux. Je vais lancer du coup une release d'eugene dans la foulée si cela ne dérange personne. tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
participants (1)
-
Tony Chemit