Source Code Generator using XMLDecoder

[Daniel Puryear]

As a study exercise I've developed a GUI builder sort'a like VisualCafe
where I persist (Save/SaveAs..) the design out using the XMLEncoder and load
it back with the XMLDecoder. Works fine for the time being. Have a crude
home grown SourceCodeGenerator that I can pass the root node of the object
tree and it spews out source code. But the thought occurs to me that I
should be able to leverage the default member filtering powers of the
XMLEncoder by using a hook into the XMLDecoder so as to produce only source
code needed to reproduce the object tree, skipping all the members that
merely have defaults.

Has anyone had experience generating source code from an object tree in
general or from the persisted XML produced by the XMLEncoder in particular
that can share some pointers and/or portions of their code?

 

[Stefan Ram]

Has anyone had experience generating source code from an object
tree in general

I am developing a crude home grown object description
generator myself that is quite unfinished. But since you have
asked ...

I do not want to use default values, but if I had to use them,
I would call the default constructor and then compare with the
values of the fields directly afterwards.

Here is an example object and its serialization:

class Ship
{ Position position;
final java.lang.String a0 = "alpha";
final java.lang.String a1 = "This is an example text.";
final java.lang.String a2 = "beta[gamma]delta[epsilon\\zeta<eta";
final java.lang.Integer[] b = new java.lang.Integer[]{ 1, 2, 3 }; }
class Position { int x; int y; }

public class Main
{ public static void main( final java.lang.String[] args )
{ Position position = new Position(); position.x = 1; position.y = 2;
Ship ship = new Ship(); ship.position = position;
java.lang.System.out.println
( new de.dclj.ram.notation.junobjects.Junobjects().dump( ship )); }}

The serialization looks as follows:

< &objectmap
object =
< &Ship
a0 =
< &java.lang.String alpha >
a1 =
< &java.lang.String [This is an example text.] >
a2 =
< &java.lang.String [beta[gamma]delta\[epsilon\zeta<eta] >
b =
< &[java.lang.Integer[]]
< &java.lang.Integer 1 >
< &java.lang.Integer 2 >
< &java.lang.Integer 3 >>
position =
< &Position zz0 >>
zz0 =
< &Position
x =
< &int 1 >
y =
< &int 2 >>>

However, there are still several important features missing.
This is an ongoing project. A call to read this in again is
not yet written.

One should be able to browse the source code (via the JavaDocs) from:

http://www.purl.org/stefan_ram/pub/ram-jar

 

[Bjorn Abelli]

...

As a study exercise I've developed a GUI builder sort'a
like VisualCafe where I persist (Save/SaveAs..)
[snip]

But the thought occurs to me that I should be able to
leverage the default member filtering powers of the XMLEncoder by using a
hook into the XMLDecoder so
as to produce only source code needed to reproduce
the object tree, skipping all the members that merely have defaults.

I made a similar thing for my students several years ago, in order to
simplify the first steps of their learning process.

However, this was long before the inclusion of the XMLEncoder in the Java
library, so I never implemented any separate saving part for the tree, but
simply generated the source code directly. In that process I excluded
setting of any members with default values in the generated source code.

I guess you've constructed something similar to filter them out when writing
the XML.

But won't the filtering of members when writing through the XMLEncoder make
it unnecessary to filter it again when reading with the XMLDecoder?

/// Bjorn A



Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

 

[Daniel]

Correct. Filtering is performed by the XMLEncoder during the serialization
hence no further filtering is required during the de-serialization. The
XMLEncoder produces a very compact serialization, including only that which
is required to reproduce the object through its default constructor. That's
also one of several reasons that makes the XMLEncoder tricky to use for all
but the simplest of cases. I've had to use the persistenceDelegate hook to
handle several of the "not so simple" cases. But then, that's also what has
me interested in using the serialized XML as the model that drives the
source code generator - compact, no nonsense source code.

...

As a study exercise I've developed a GUI builder sort'a
like VisualCafe where I persist (Save/SaveAs..)
[snip]

But the thought occurs to me that I should be able to
leverage the default member filtering powers of the XMLEncoder by using a
hook into the XMLDecoder so
as to produce only source code needed to reproduce
the object tree, skipping all the members that merely have defaults.

I made a similar thing for my students several years ago, in order to
simplify the first steps of their learning process.

However, this was long before the inclusion of the XMLEncoder in the Java
library, so I never implemented any separate saving part for the tree, but
simply generated the source code directly. In that process I excluded
setting of any members with default values in the generated source code.

I guess you've constructed something similar to filter them out when
writing the XML.

But won't the filtering of members when writing through the XMLEncoder
make it unnecessary to filter it again when reading with the XMLDecoder?

/// Bjorn A



Inviato da X-Privat.Org - Registrazione gratuita
http://www.x-privat.org/join.php