Re: [xngr-dev] xngr reusage notice

Edwin Dankert wrote:
> 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 actually speaking of the service part in this case - I was hoping
to plug in my own element factory and have the xngr manage a tree
with some gui actions attached. The gui would then call into the
service plugin with the corresponding element.

Now actually I did already have functionality available for a node but
it was using my own element class. Here I can easily implement any
interface needed by the xngr part - but XElement did turn out to be
not enough.

Reusing the widgetry is still ahead of me, work is underway with that.
I could only start with it after making the necessary changes to the
xngr xml tree handling. I hope to have a new widget group available
in the next few days. For now, the xngr explorer/desktop is used as is
with a seperate smacs service plugin loaded.

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

I wouldn't like integrated approaches all too well - there are too many
integrated approaches in the xml java world already, requiring dozens
of dependencies on something. My application is going to be standalone
and simply something a compiler tool. Including commandline interfaces
running without any gui whatsoever.

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

Your welcome, - a developer snapshot can be found at
http://www.informatik.hu-berlin.de/~draheim/diplom/
in the latest smacs-*.tar.gz in /smacs/gui/xngr/browser/*
part. Note that the sources can not be easily copied out
of the smacs tree at the moment, it's really a snapshot.

-- Have fun, guido

> 
> Regards,
> Edwin Dankert
> 
> ----- Original Message ----- 
> From: "Guido Draheim" <[email protected]>
> To: <[email protected]>
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xngr-development
> 
> 




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