Re: [xngr-dev] xngr reusage notice

[Edwin D. <eda...@cl...>]

Hello Guido,

Thanks for your contribution.

> It does turn out that large parts of the xngr are not based on the
> outer XElement interface or something similar.

I think you run into problems here because it was never envisaged to reuse
the 'Browser' part of the project, the API was only intented to support
pluggable 'Services'.

> I am now wondering whether the xngr developers want to have a look
> and merge with the changes I have made.

I think that extending the code according to your description might result
in a very flexible browser structure and I would love to see your code and
possibly integrate your code in the main Exchanger XML Browser branch.

I however have been thinking about a new 'component based' approach for the
'XML Browser' based on the apache avalon framework and possibly Cocoon, am
very busy at the moment with the 'XML Editor' but I would like to
investigate this further and possibly integrate your changes at the same
time ...

> Atleast I did want to inform you that xngr is now reused by
> me, in a modified variant.

Thanks for that.

Regards,
Edwin Dankert

----- Original Message ----- 
From: "Guido Draheim" <gui...@gm...>
To: <xng...@li...>
Sent: Sunday, April 11, 2004 4:55 AM
Subject: [xngr-dev] xngr reusage notice


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++



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
xngr-development mailing list
xng...@li...
https://lists.sourceforge.net/lists/listinfo/xngr-development