Thread: [xngr-dev] xngr reusage notice

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi there,

I was thinking to use xngr as the xml browsing component in my own
application. It did turn out however that the XService / *Factory
implementation did not work as hoped for. The Xngr will always
import an xml tree with its own xml node variant being those
ExchangerElement ones. However, large parts of my own functionality
is based on my own xml node variant - which is also derived from
dom4j.DefaultElement.

It does turn out that large parts of the xngr are not based on the
outer XElement interface or something similar. When browsing
through the xngr browser sources one can see that the real
implementation is actually _dependent_ on functionality of the
subclasses named Exchanger* - using anything different might
even provoke nullpointer exceptions.

The latter seems to be based on the fact that some functionality
in the xngr browser is guarded with "instanceof Exchanger*" checks
that will make some parts uninitialized. I was shortly trying to find
a way around it without much success. I did skip that after all and
gone the good path.

The changes to the xngr browser part have been to not change
the implementation of the subcomponents and instead create a
new subdirectory "exchanger/" with copies of Exchanger* sources
(thereby named Exchanger* -> Xngr*) and skeletizing the originals
to become an _interface_ each. The old/new Xngr*.java sources
will now happily be implementing the public Exchanger*-interfaces.

public class XngrElement extends DefaultElement implements ExchangerElement

That for a fact allows me to build my own node-type that is also
an implementation of the ExchangerElement interface. And oops,
that makes for correct functioning of the xngr browser even with
my own dom4j node subclass. With one additition.

It turns out that large parts of the xngr browser components do
not only expect objects as arguments but they do in fact also
_create_ new instances - and _without_ the help of call to a factory
singleton. They just do "new Exchanger*"- something.

So, yet another change did need to assemble all the "new Exchanger"
calls on a new global singleton factory having methods named like
"newExchangerElement" with the synopsis of those being in actual
usage. Now I can even subclass that explicit class, overrding some
of the newObject methods, and assigning the subclass as the
singleton object.

Currently I am about to disintegrate the "*Confguration" stuff in
similar ways - of course my application has its own ways of
storing configuration parts. It goes along the same lines, by making
the original names into interfaces that is implemented in the
properties/ part as being based on xngr.xml.

My project is far from finished, probably going to be completed
in august something - at which point the sources need to be
published according to MPL rules. During development I have
been embedding the xngr sources which did help me along the
way up to now. I need to separate the modified xngr sources of
course before going to ship my own application, so I am free
from license restrictions for my own parts.

After all the changes above however, I am now at a point where
I can separate out the modified xngr cleanly. That wasn't possible
until recently where I did need to implant dependencies on my
own implementation variants of nodes and methods, and directly
within the xngr components. An hour ago I was able to cut off
the last of those dependency. Hooray ;-)

I am now wondering whether the xngr developers want to have
a look and merge with the changes I have made. It is perfectly
fine for me to live with the split and a modified variant. And may
be I'll do more to it until august, so I leave it up to you. Perhaps
we should just wait until its finished and published as an offspring
according to MPL rules. Atleast I did want to inform you that
xngr is now reused by me, in a modified variant.

And btw, javadoc was not happy with the current xngr source tree.

have fun,
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ s+:a d(+-) r+@>+++ y++

Thread: [xngr-dev] xngr reusage notice

xngr-development