xngr-development Mailing List for XNGR XML Browser
Brought to you by:
edankert
Menu
▾
▴
xngr-development — An email list for developers of the eXchaNGeR application.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
(8) |
Nov
(15) |
Dec
(26) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(4) |
Feb
(5) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: EU B. R. <reg...@eu...> - 2017-06-23 21:27:45
|
Hello, In order to have your company inserted in the EU Business Register for 2017/2018, please print, complete and submit the attached form (PDF file) to the following address: EU BUSINESS REGISTER P.O. BOX 34 3700 AA ZEIST THE NETHERLANDS Fax: +31 205 248 107 You can also scan the completed form and attach it in a reply to this email. Updating is free of charge. |
|
From: EU B. R. <reg...@eb...> - 2017-02-16 17:31:21
|
In order to have your company inserted in the EU Business Register for 2017/2018, please print, complete and submit the attached form (PDF file) to the following address: EU BUSINESS REGISTER P.O. BOX 34 3700 AA ZEIST THE NETHERLANDS Fax: +31 205 248 107 You can also scan the completed form and attach it in a reply to this email. Updating is free of charge. |
|
From: Plate H. E. <ga...@ph...> - 2015-11-25 20:21:24
|
<html>
<head>
<title></title>
<meta content="text/html; charset=gb2312" http-equiv="Content-Type" />
</head>
<body>
<div><font face="@Arial Unicode MS">Dear purchasing manager, </font></div>
<div><font face="@Arial Unicode MS"> </font></div>
<div><font face="@Arial Unicode MS">Hello,this Jay from WTSML PHE SERVICE,our company is a professional Heat Exchanger manufacturer with years's experience.</font></div>
<div><font face="@Arial Unicode MS">so we want to avail ourselves of opportunity establishing business relation with you. </font></div>
<div><font face="@Arial Unicode MS">Please link our company web site: www.phe-service.com if you want to know more about our product. </font></div>
<div><font face="@Arial Unicode MS">Thank you in advance!</font></div>
<div><font face="@Arial Unicode MS"> </font></div>
<div>
<div>
<p style="margin-bottom: 0pt; font-size: 66px"><span style="font-size: 16pt; font-family: Calibri"><font size="3" face="@Arial Unicode MS">Best Regards </font></span><font face="@Arial Unicode MS"><font size="3"><span style="font-size: 16pt; font-family: Calibri"> <br style="font-size: 24pt" /><span style="font-size: 16pt; font-family: Calibri; color: #000000"><font size="4">Jay Lin</font></span></span><span style="font-size: 16pt; font-family: Calibri; color: #000000"> </span></font></font></p>
<div style="font-size: 16pt; font-family: Calibri; color: #000000"><font size="3" face="@Arial Unicode MS">WTSML PHE Service</font></div>
<div style="font-size: 16pt; font-family: Calibri; color: #000000"><font size="3" face="@Arial Unicode MS">Phone:86 595 22168106</font></div>
<div style="font-size: 16pt; font-family: Calibri; color: #000000"><font size="3" face="@Arial Unicode MS">Web:<font size="4" face="Calibri">www.phe-gasket.com</font></font></div>
<div style="font-size: 16pt; font-family: Calibri; color: #000000"><font size="4" face="@Arial Unicode MS"> </font></div>
</div>
</div>
</body>
</html> |
|
From: Publisher N. <joh...@pu...> - 2014-07-24 03:39:03
|
Not received in your language? Click here: <http://mailservice.pulse-targeting.com/lists/lt.php?id=bEQCDgdQBwBSUEkBB1RLUVMLD1IH> <http://mailservice.pulse-targeting.com/lists/lt.php?id=bEQCDgdQBwBSUEkBB1RLUVMLD1IH> Dear Webmaster, While navigating your website, we noticed you host advertising spaces. We are contacting you because we would like to introduce our digital services for Web Publishers. We are able to purchase any advertsing space (ad unit) you may have available or unsold. Our RTB technology purchases your impressions CPM based on your website surfers behavior. Several Ad Display sizes available and Pop-unders for an high eCPM. *SOME OF YOUR ADVANTAGES:* • $ 25.00 Credit Bonus to register your website. • CPM: Your Ad Units are sold CPM, based on your website surfers behavior, in Real Time Bidding. • Are you approved by Adsense? Increase your income by adding the 4th DoubleClick Ad Unit in each page. • Does your website generate millions of impressions? A dedicated account manager will work with you to optimize your income. • Pass-Back Tag: If you are eligible, we purchase only the impressions according to your requested minimum CPM. • Pop-Unders: Add a pop-under and get a high eCPM. • …and much more… OxaMedia is a Global Adnetwork of Advertisers and Publishers. <http://mailservice.pulse-targeting.com/lists/lt.php?id=bEQCDgdQBwBSUEkBB1RLUVMLD1IH> The OxaMedia RTB Technology offers the opportunity for *registered Publishers to sell their impressions* based on the website users behavior. In the list on the left you can find some of the *many advantages that we guarantee to our publishers.* If you wish to learn more about us or to register, please click here <http://mailservice.pulse-targeting.com/lists/lt.php?id=bEQCDgdQBwBSUEkBB1RLUVMLD1IH> , or contact our Support Team <http://mailservice.pulse-targeting.com/lists/lt.php?id=bEQCDgdQBwBSV0kBB1RLUVMLD1IH> . We are always available to respond to any information requests and we hope to have you among our Top Publishers as soon as possible. <http://mailservice.pulse-targeting.com/lists/lt.php?id=bEQCDgdQBwBSUEkBB1RLUVMLD1IH> Thank you for your consideration and we apologize for any inconvenience this e-mail may have caused you. Best Regards, OxaMedia Publisher Team <http://mailservice.pulse-targeting.com/lists/lt.php?id=bEQCDgdQBwBSUEkBB1RLUVMLD1IH> -- If you do not want to receive any more newsletters, http://mailservice.pulse-targeting.com/lists/lt.php?id=bEQCDgdQBwBSVkkBB1RLUVMLD1IH |
|
From: Reid L. <rei...@ne...> - 2013-09-19 22:26:16
|
Select your language: <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQADQZTAQNVUUkBBFZLUVMLD1IH> Dear Webmaster, visiting your website we noticed you host some ad spaces. We are contacting you in order to introduce you our Adnetwork, which offers digital advertising solutions for publishers. € 25,00 welcome bonus to register your website Optimized targeted advertising to reach an high eCPM Guaranteed payments of your monthly profits Control panel with access to real-time statistics No exclusive contract: add even a single OxaMedia banner and continue collaborationg with your other ad providers. Support and a manager account dedicated ...and much more.. OxaMedia is a global Adnetwork <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQADQZTAQNVUUkBBFZLUVMLD1IH> that collaborates with Top Advertisers all over the world and is connected with the major AdExchanges in order to distribute on publisher websites high quality ads. If you wish to learn more about our AdNetwork, please click here <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQADQZTAQNVUUkBBFZLUVMLD1IH> , or fill out our Support <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQADQZTAQNVUEkBBFZLUVMLD1IH> form. Should you have any questions, please feel free to contact us we hope to have you as soon as possible among our Top Publishers. <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQADQZTAQNVUUkBBFZLUVMLD1IH> Kind regards. OxaMedia AdNetwork Team <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQADQZTAQNVUUkBBFZLUVMLD1IH> ** ** -- If you do not want to receive any more newsletters, http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQADQZTAQNVV0kBBFZLUVMLD1IH |
|
From: Reid L. <rei...@ne...> - 2013-07-15 19:47:03
|
Select your language: <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQHAAFUBgNSUEkJDBgEVVcOCFA%3D> Dear Webmaster, visiting your website we noticed you host some ad spaces. We are contacting you in order to introduce you our Adnetwork, which offers digital advertising solutions for publishers. € 25,00 welcome bonus to register your website Optimized targeted advertising to reach an high eCPM Guaranteed payments of your monthly profits Control panel with access to real-time statistics No exclusive contract: add even a single OxaMedia banner and continue collaborationg with your other ad providers. Support and a manager account dedicated ...and much more.. OxaMedia is a global Adnetwork <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQHAAFUBgNSUEkJDBgEVVcOCFA%3D> that collaborates with Top Advertisers all over the world and is connected with the major AdExchanges in order to distribute on publisher websites high quality ads. If you wish to learn more about our AdNetwork, please click here <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQHAAFUBgNSUEkJDBgEVVcOCFA%3D> , or fill out our Support <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQHAAFUBgNSV0kJDBgEVVcOCFA%3D> form. Should you have any questions, please feel free to contact us we hope to have you as soon as possible among our Top Publishers. <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQHAAFUBgNSUEkJDBgEVVcOCFA%3D> Kind regards. OxaMedia AdNetwork Team <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQHAAFUBgNSUEkJDBgEVVcOCFA%3D> ** ** -- If you do not want to receive any more newsletters, http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQHAAFUBgNSVkkJDBgEVVcOCFA%3D |
|
From: Reid L. f. P. <rei...@ne...> - 2013-06-13 22:50:06
|
Not received in your language? Click here: <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQGDABQAwBdV0kIARgEVVcOCFA%3D> <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQGDABQAwBdV0kIARgEVVcOCFA%3D> Dear Webmaster, While navigating your website, we noticed you host advertising spaces. We are contacting you because we would like to introduce our digital services for Web Publishers. We are able to purchase any advertsing space (ad unit) you may have available or unsold. Our RTB technology purchases your impressions CPM based on your website surfers behavior. *SOME OF YOUR ADVANTAGES:* • $ 25.00 Credit Bonus to register your website. • CPM: Your Ad Units are sold CPM, based on your website surfers behavior, in Real Time Bidding. • Are you approved by Adsense? Increase your income by adding the 4th DoubleClick Ad Unit in each page. • Does your website generate millions of impressions? A dedicated account manager will work with you to optimize your income. • Pass-Back Tag: If you are eligible, we purchase only the impressions according to your requested minimum CPM. • No Exclusive Contract: Our system enables full compatibility with your usual ad providers. • …and much more… OxaMedia is a Global Adnetwork of Advertisers and Publishers. <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQGDABQAwBdV0kIARgEVVcOCFA%3D> The OxaMedia RTB Technology offers the opportunity for *registered Publishers to sell their impressions* based on the website users behavior. In the list on the left you can find some of the *many advantages that we guarantee to our publishers.* If you wish to learn more about us or to register, please click here <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQGDABQAwBdV0kIARgEVVcOCFA%3D> , or contact our Support Team <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQGDABQAwBdVkkIARgEVVcOCFA%3D> . We are always available to respond to any information requests and we hope to have you among our Top Publishers as soon as possible. <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQGDABQAwBdV0kIARgEVVcOCFA%3D> Thank you for your consideration and we apologize for any inconvenience this e-mail may have caused you. Best Regards, OxaMedia Publisher Team <http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQGDABQAwBdV0kIARgEVVcOCFA%3D> -- If you do not want to receive any more newsletters, http://mailservice.nextwebcorp.com/lists/lt.php?id=bEQGDABQAwBdVUkIARgEVVcOCFA%3D |
|
From: Reid L. <rei...@ip...> - 2013-04-02 19:48:20
|
Not received in your language? Click here: <http://mailservice.ipodchrome.net/lists/lt.php?id=bEQBCwBQAwZRHwMISFcAUVIJCg%3D%3D> <http://mailservice.ipodchrome.net/lists/lt.php?id=bEQBCwBQAwZRHwMISFcAUVIJCg%3D%3D> Dear Webmaster, While navigating your website, we noticed you host advertising spaces. We are contacting you because we would like to introduce our digital services for Web Publishers. We are able to purchase any advertsing space (ad unit) you may have available or unsold. Our RTB technology purchases your impressions CPM based on your website surfers behavior. *SOME OF YOUR ADVANTAGES:* • $ 25.00 Credit Bonus to register your website. • CPM: Your Ad Units are sold CPM, based on your website surfers behavior, in Real Time Bidding. • Are you approved by Adsense? Increase your income by adding the 4th DoubleClick Ad Unit in each page. • Does your website generate millions of impressions? A dedicated account manager will work with you to optimize your income. • Pass-Back Tag: If you are eligible, we purchase only the impressions according to your requested minimum CPM. • No Exclusive Contract: Our system enables full compatibility with your usual ad providers. • …and much more… OxaMedia is a Global Adnetwork of Advertisers and Publishers. <http://mailservice.ipodchrome.net/lists/lt.php?id=bEQBCwBQAwZRHwMISFcAUVIJCg%3D%3D> The OxaMedia RTB Technology offers the opportunity for *registered Publishers to sell their impressions* based on the website users behavior. In the list on the left you can find some of the *many advantages that we guarantee to our publishers.* If you wish to learn more about us or to register, please click here <http://mailservice.ipodchrome.net/lists/lt.php?id=bEQBCwBQAwZRHwMISFcAUVIJCg%3D%3D> , or contact our Support Team <http://mailservice.ipodchrome.net/lists/lt.php?id=bEQBCwBQAwZQHwMISFcAUVIJCg%3D%3D> . We are always available to respond to any information requests and we hope to have you among our Top Publishers as soon as possible. <http://mailservice.ipodchrome.net/lists/lt.php?id=bEQBCwBQAwZRHwMISFcAUVIJCg%3D%3D> Thank you for your consideration and we apologize for any inconvenience this e-mail may have caused you. Best Regards, OxaMedia Publisher Team <http://mailservice.ipodchrome.net/lists/lt.php?id=bEQBCwBQAwZRHwMISFcAUVIJCg%3D%3D> -- If you do not want to receive any more newsletters, http://mailservice.ipodchrome.net/lists/lt.php?id=bEQBCwBQAwZTHwMISFcAUVIJCg%3D%3D |
|
From: Reid L. <rei...@be...> - 2013-03-01 21:16:20
|
Not received in your language? Click here: <http://mailservice.bewebstream.com/lists/lt.php?id=bEQCDgNVAgIZVgxMB1MEVFUL> <http://mailservice.bewebstream.com/lists/lt.php?id=bEQCDgNVAgIZVgxMB1MEVFUL> Dear Webmaster, While navigating your website, we noticed you host advertising spaces. We are contacting you because we would like to introduce our digital services for Web Publishers. We are able to purchase any advertsing space (ad unit) you may have available or unsold. Our RTB technology purchases your impressions CPM based on your website surfers behavior. *SOME OF YOUR ADVANTAGES:* • $ 25.00 Credit Bonus to register your website. • CPM: Your Ad Units are sold CPM, based on your website surfers behavior, in Real Time Bidding. • Are you approved by Adsense? Increase your income by adding the 4th DoubleClick Ad Unit in each page. • Does your website generate millions of impressions? A dedicated account manager will work with you to optimize your income. • Pass-Back Tag: If you are eligible, we purchase only the impressions according to your requested minimum CPM. • No Exclusive Contract: Our system enables full compatibility with your usual ad providers. • …and much more… OxaMedia is a Global Adnetwork of Advertisers and Publishers. <http://mailservice.bewebstream.com/lists/lt.php?id=bEQCDgNVAgIZVgxMB1MEVFUL> The OxaMedia RTB Technology offers the opportunity for *registered Publishers to sell their impressions* based on the website users behavior. In the list on the left you can find some of the *many advantages that we guarantee to our publishers.* If you wish to learn more about us or to register, please click here <http://mailservice.bewebstream.com/lists/lt.php?id=bEQCDgNVAgIZVgxMB1MEVFUL> , or contact our Support Team <http://mailservice.bewebstream.com/lists/lt.php?id=bEQCDgNVAgEZVgxMB1MEVFUL> . We are always available to respond to any information requests and we hope to have you among our Top Publishers as soon as possible. <http://mailservice.bewebstream.com/lists/lt.php?id=bEQCDgNVAgIZVgxMB1MEVFUL> Thank you for your consideration and we apologize for any inconvenience this e-mail may have caused you. Best Regards, OxaMedia Publisher Team <http://mailservice.bewebstream.com/lists/lt.php?id=bEQCDgNVAgIZVgxMB1MEVFUL> -- If you do not want to receive any more newsletters, http://mailservice.bewebstream.com/lists/lt.php?id=bEQCDgNVAgAZVgxMB1MEVFUL |
|
From: Edwin D. <eda...@gm...> - 2007-07-02 09:01:45
|
I'm sorry for the unexpected code changes but I wasn't aware that people were using the current code, I have created a version tag V101 for people that want to get the code for the 1.1 version. I have started work on the new 2.0 version of the XML browser, this will involve major changes to both the services APIs as the browser part. At the moment I have the following changes in mind: The main idea of the XML browser will stay the same but the services API will become simpler and will be more based on open standards, using JAXP functionality instead of dom4j functionality. The API will also look more like it does in eclipse with the use of multiple extension-points and some of the terminology might also change to be more in line with eclipse. The idea is that people for version 2.0 of the XML browser can provide any number of services but can also easily provide new browser implementations. I am planning to release 2 different browser implementations: - one that allows users to browse and explore directories - and one that allows to browse and bookmark xml documents But it should also be easy enough to create a browser implementation which is build into eclipse and one that allows to browse a xml database. All these browsers (although not sure about the eclipse version yet) should be able to use the same services. This means that there will be 2 different APIs, one for Service providers and one for Browser providers. I will try to get beta versions of these new APIs ready as soon as possible to get some feedback. This is currently still in design phase, so any suggestions are very welcome. Kind regards, Edwin -- http://www.edankert.com/ |
|
From: Vishal B. <vbh...@gm...> - 2007-06-29 15:33:20
|
Sorry for the multiple posts. I found that XElementType.java was removed in
the last commit (6/28/07):
$ cvs log XElementType.java
RCS file: /cvsroot/xngr/xngr/src/org/xngr/Attic/XElementType.java,v
Working file: XElementType.java
head: 1.3
branch:
locks: strict
access list:
symbolic names:
V011: 1.2
V08: 1.2
V06: 1.2
V05: 1.1.1.1
V02: 1.1.1.1
Initial_V01: 1.1.1.1
Cladonia: 1.1.1
keyword substitution: kv
total revisions: 4; selected revisions: 4
description:
----------------------------
revision 1.3
date: 2007/06/28 13:14:19; author: edankert; state: dead; lines: +2 -2
Clean up, removed dom4j, use generics and security manager stuff.
----------------------------
revision 1.2
date: 2002/08/19 20:08:09; author: edankert; state: Exp; lines: +3 -3
Handle universal names without namespaces correctly. {}
----------------------------
revision 1.1
date: 2002/02/16 16:12:49; author: edankert; state: Exp;
branches: 1.1.1;
Initial revision
----------------------------
revision 1.1.1.1
date: 2002/02/16 16:12:49; author: edankert; state: Exp; lines: +0 -0
Initial import
=============================================================================
Looks like it was removed by mistake. Also, I am not sure why dom4j.jar was
removed. I had to use a local copy of dom4j.jar to compile.
Cheers.
|
|
From: Vishal B. <vbh...@gm...> - 2007-06-29 15:08:10
|
Hi everyone! I got the latest code from HEAD for xngr module this morning and I discovered that org.xngr.XElementType class has been completely removed. Now I am getting compilation errors. Any clues as to why it was removed? Or am I doing something wrong? Cheers, Vishal |
|
From: SourceForge.net <no...@so...> - 2005-11-04 09:17:20
|
Bugs item #1348064, was opened at 2005-11-04 01:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=1348064&group_id=46235 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: explorer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: no categories available after service added Initial Comment: I can add services in 'desktop', but no categories appear under 'Categories' in Explorer, and all tool icons remain greyed. Using JRE Version 1.5.0 (build 1.5.0_05-b05) Nothing appears in Java console. Running xngr v1.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=1348064&group_id=46235 |
|
From: Edwin D. <eda...@cl...> - 2004-04-12 18:27:14
|
Hello Guido, > 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. My mistake, that sounds very interesting, however, I didn't foresee this either. > 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. I am not so sure anymore about the XElement and XDocument interfaces, maybe we should just allow people to work with the underlying (extended) DOM4J objects instead. (this seems to be what you're doing anyway?) They were meant to hide complex DOM4J specific behavior. > 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. Good luck with that. > 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. The Avalon architecture is just so beautiful, don't think I can resist the call ;-) > My application is going to be standalone and simply something a > compiler tool. Including commandline interfaces running without > any gui whatsoever. I had a look at some of the documentation and have no idea what you're trying to do but it sounds interesting, I'll have a closer look at the code sometime this week. Good luck, Edwin |
|
From: Guido D. <gui...@gm...> - 2004-04-12 17:38:34
|
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" <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 > > |
|
From: Edwin D. <eda...@cl...> - 2004-04-12 17:16:37
|
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 |
|
From: Guido D. <gui...@gm...> - 2004-04-11 03:55:31
|
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++ |
|
From: PCHOME<4xn...@ms...> - 2004-03-15 05:02:02
|
------=_NextPart_000_00E0_01C34495.FA087520 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E1_01C34495.FA087520" ------=_NextPart_001_00E1_01C34495.FA087520 Content-Type: text/html; charset="Big5" Content-Transfer-Encoding:Base64 PGh0bWw+DQoNCjxoZWFkPg0KPG1ldGEgbmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJNaWNyb3Nv ZnQgRnJvbnRQYWdlIDUuMCI+DQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNvbnRlbnQ9IkZyb250UGFn ZS5FZGl0b3IuRG9jdW1lbnQiPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9YmlnNSI+DQo8dGl0bGU+xF+49K71u3Oqr625vMiwsaVY pGY8L3RpdGxlPg0KPHN0eWxlPg0KPCEtLQ0KcHtmb250LXNpemU6MTI1JTtsaW5lLWhlaWdodDox LjU7fS0tPg0KPC9zdHlsZT4NCjwvaGVhZD4NCg0KPGJvZHk+DQoNCjxwPjxhIGNsYXNzPSJ0aXRs ZSIgaHJlZj0iaHR0cDovL3R3Lm5ld3MueWFob28uY29tLzA0MDMwOS80L2kyYjYuaHRtbCI+DQrE X7j0rvW7c6qvrbm8yLCxpVikZjwhLS0gMjAwNDAzMDkgLS0+PC9hPiA8Zm9udCBjb2xvcj0iIzY2 NjY2NiI+DQo8c21hbGwgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsgbGluZS1oZWlnaHQ6IDEuNSI+ KKSkvHO3c7tEuvQpPC9zbWFsbD48L2ZvbnQ+PGJyPg0KPGJyPg0KPGJpZyBzdHlsZT0iZm9udC1z aXplOiAxMjUlOyBsaW5lLWhlaWdodDogMTY2JSI+DQqhQKXNsqPEX7j0qq+5fa7Gqrqm46ripL2l cartpdyhQaXRqfO+4aTfxF+49KZirvWw6qXNsqOquqqvuX2uxqVpr+CpTaqvqOC1x7BJutyms8P2 oUGm46ripHe4Z7CxpO6/6aVYqq+5fa7GqOyqRqtuqMiw6q5hoUOhQKFAoUChQKXRqfOmYqV4xlez b7RYrdOk66azpKOk1qZZpEbEX7j0qq+5fa7Gqrqqr6XNr2ahQabjquKoTal3pmKu9bDqpFesW6q6 xF+49KqvuX2uxqtosU6xxKj6ptvEQKZepqyquqTopqGhQ6bjquKkvaVxqrrBbqn6u6GhQaS9pXGk 6K2xpHe4Z8RZrubAy8XnpEazb6flqq+5fa7GoUGo7KXYq2WssKTuwdmoU7VvsnsuLi48L2JpZz48 L3A+DQoNCjxpbWcgc3JjPWh0dHA6Ly93d3cucHJvOGxpc3QuY29tL21haWx0ZW1wL2FkZGVtYWls dHcuYXNwP2VtYWlsPXhuZ3ItZGV2ZWxvcG1lbnRAbGlzdHMuc291cmNlZm9yZ2UubmV0PjwvYm9k eT4NCg0KPC9odG1sPg0K ------=_NextPart_001_00E1_01C34495.FA087520-- ------=_NextPart_000_00E0_01C34495.FA087520-- |
|
From: SourceForge.net <no...@so...> - 2003-03-31 09:09:02
|
Feature Requests item #712573, was opened at 2003-03-31 09:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445489&aid=712573&group_id=46235 Category: None Group: None Status: Open Priority: 8 Submitted By: Edwin Dankert (edankert) Assigned to: Edwin Dankert (edankert) Summary: Font selection Initial Comment: Allow the user to select different fonts for the editor and the viewer. This should make different character-sets visible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445489&aid=712573&group_id=46235 |
|
From: SourceForge.net <no...@so...> - 2003-03-31 09:05:30
|
Bugs item #712571, was opened at 2003-03-31 09:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=712571&group_id=46235 Category: editor Group: 1.0 Status: Open Resolution: None Priority: 8 Submitted By: Edwin Dankert (edankert) Assigned to: Edwin Dankert (edankert) Summary: Wrong encoding handling Initial Comment: The XML encoding handling is wrong, this could result in data-loss and does not allow for Chinese, Japanese and other characters. (The XML encoding currently supported is US-ASCII instead of the UTF-8 defaulted by the editor.) All encodings supported by dom4j and xerces should be handled correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=712571&group_id=46235 |
|
From: SourceForge.net <no...@so...> - 2003-03-18 15:46:30
|
Bugs item #705666, was opened at 2003-03-18 07:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=705666&group_id=46235 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Test Parameters for Remote Initial Comment: There appears to be no way to send POST method fields to a remote host when requesting XML for viewing/analysis. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=705666&group_id=46235 |
|
From: SourceForge.net <no...@so...> - 2003-03-18 15:43:22
|
Bugs item #705664, was opened at 2003-03-18 07:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=705664&group_id=46235 Category: viewer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: No SSL Authentication Initial Comment: Application does not request userid/password for remote document required by SSL basic authentication. Instead, immediately returns error 401. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=705664&group_id=46235 |
|
From: SourceForge.net <no...@so...> - 2003-02-19 18:21:43
|
Bugs item #689498, was opened at 2003-02-19 18:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=689498&group_id=46235 Category: explorer Group: 1.0 Status: Open Resolution: None Priority: 3 Submitted By: Edwin Dankert (edankert) Assigned to: Edwin Dankert (edankert) Summary: Inconsistent UI Initial Comment: The UI is not conform UI guidelines: - Menus change depending on document state, should be enabled/disabled instead. - No open menu item in file menu, - and other inconsistencies. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=689498&group_id=46235 |
|
From: SourceForge.net <no...@so...> - 2003-02-19 18:14:08
|
Bugs item #689489, was opened at 2003-02-19 18:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=689489&group_id=46235 Category: editor Group: 1.0 Status: Open Resolution: None Priority: 6 Submitted By: Edwin Dankert (edankert) Assigned to: Edwin Dankert (edankert) Summary: Out of memory, saving large document Initial Comment: The following exception occurs saving a large XML document. (1200 DocBook pages) Together with the exception a dialog saying "An external process has changed the document, do you want to discard the changes?" appears: java.lang.OutOfMemoryError org.xml.sax.SAXParseException: Premature end of file. at org.apache.xerces.parsers.AbstractSAXParser.parse (AbstractSAXParser.java:1189) at org.dom4j.io.SAXReader.read(SAXReader.java:323) at org.dom4j.io.SAXReader.read(SAXReader.java:218) at org.xngr.browser.util.DocumentUtilities.readDocum ent(DocumentUtilities.java:144) at org.xngr.browser.ExchangerDocument.load (ExchangerDocument.java:382) at org.xngr.browser.ExchangerDocument.consistent (ExchangerDocument.java:428) at org.xngr.browser.ExchangerDocument.access$000 (ExchangerDocument.java:64) at org.xngr.browser.ExchangerDocument$4.actionPerf ormed(ExchangerDocument.java:516) at javax.swing.Timer.fireActionPerformed (Timer.java:271) at javax.swing.Timer$DoPostEvent.run (Timer.java:201) at java.awt.event.InvocationEvent.dispatch (InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent (EventQueue.java:443) at java.awt.EventDispatchThread.pumpOneEventForHie rarchy(EventDispatchThread.java:191) at java.awt.EventDispatchThread.pumpEventsForHierar chy(EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:138) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:130) at java.awt.EventDispatchThread.run (EventDispatchThread.java:98) -------------------------- Workaround Try changing the memory heap with the -mx parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=689489&group_id=46235 |
|
From: SourceForge.net <no...@so...> - 2003-02-18 10:07:55
|
Bugs item #688565, was opened at 2003-02-18 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=688565&group_id=46235 Category: explorer Group: All Status: Open Resolution: None Priority: 5 Submitted By: Klaus Johannes Rusch (krusch) Assigned to: Nobody/Anonymous (nobody) Summary: Explorer typo Initial Comment: "Explorer" is misspelled as "Exporer" in the bubble showing when hoovering over the icon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=445486&aid=688565&group_id=46235 |
4 messages has been excluded from this view by a project administrator.
