Javabean Editors


Ajouté ceci dans build.xml de raptor:
<target name="javadoc" depends="init" >
<javadoc destdir="javadoc" access="private" source="1.4" use="true" notree="false" nonavbar="false" noindex="false" splitindex="true" author="true" version="true" nodeprecatedlist="false" nodeprecated="false"
sourcepath="src/java" overview="overview.html"
docencoding="iso-8859-1" >
<fileset dir="${basedir}/lib">
<include name="**/*.jar"/>
<link href=""/>


Dans ma longue quête d'éditeur générique JavaBean, j'ai essayé raptor : un bon canditat, mais semble trop compliqué pour personaliser les formulaires par défaut.

Classe avec propriétés à la JavaBean:
Classe de Test qui lance la fenêtre formulaire:
for f in lib/*.jar ; do cp=$cp:$f ; done 
javac -classpath $cp:.:dist/Raptor.jar
java -cp $cp:.:dist/Raptor.jar Test&
Les propriétés numériques sont bien prises en compte dans les formulaires. Mais la version 0.2 ne prend pas en compte les propriétés indicées (exception IllegalArgumentException).
Je vois que le CVS a des choses en plus que la version 0.2 qui date du 2003-12-16 . Je prends:
cvs login
cvs -z3 co raptor

Hélas ça ne marche pas plus avec la dernière version.
For years I have been developing simulation software, and for years I have searched ways of making input forms generically. When the project is XML-centered, there are solutions based on XML Schema aware editors such as Pollo, GenDiapo, or Xerlin; also solutions based on XForms editors; all this in Java and open source.
And when the project is java-centered, a natural solution is to use JavaBean techniques. For example I tried to extract out of NetBeans the class pertaining to this, but it was impossible to do in a short time.

For a project I reused and adapted this:

I slightly updated the bean peeler library:
- make the panel easier to use independantly from the frame
- upgraded to swing
(there is a test main() in class BeanPeelerPane )

Enough with the context, now about the requirements:
  • allow to recursively walk through the bean
  • while doing this, take in account the cycles in object graph (don't open twice an editor for an object in a cycle of referencing objects)
  • leverage on Javabean standards and swing standards (possibly use XMLEncoder and XMLDecoder to keep config., but introduce the least possible quantity of XML, this library should be Java and Object Oriented centered); an idea is to use the tool itself to configure the editor; that means : a second instance of JavaBean editor could be used to configure the user JavaBean editor
  •  for numerical properties: editor config.:
    •   min., max., and default
    •   standard text field or slider