hi andrzej,
good job. actually, i had a similar idea during breakfast. comments inline.
Andrzej Jan Taramina wrote:
Joern/Uli:
[1] we submit our experience to the commons jxpath group which has been
proven very quick in fixing issues - at least the attribute handling in
DOM is at least strange. we can also report the probs with writing mixed
content. [2] i remember that we had a well-tested solution based on plain DOM
before the jxpath solution. - these were a bunch on method in instance that
did it the old school way. i've already found the right version (1.88) in
Chiba1 and i think we can re-activate this implementation without too much
hassle. cause these methods are quite generic they can become a static utility
class.
I looked at this further....JXPath won't help us much since you can't create
text DOM nodes directly (eg. doing a create using an xpath like
"/root/elem/text()" causes an exception in JXPath). The JXPath folks would
have to extend their API to allow this kind of operation, which will take a
while and time is something I don't have enough of right now on this project.
yep. that's why i was thinking about an own JXPath object model allowing
these operations (as well as creating attributes and so on).
Uli suggested that I disable the relevancy checking in the Submission class,
but I really didn't want to do that, since I may need to use relevancy down
the road.
just to be complete: disabling relevancy checking during submit won't
disable the relevancy processing according to the ui. it would only be
disabled for instance data serialization. but i see this as a quick
hack, not very promising.
So....I fixed it myself. Basically, I managed to get JXPath to give me not
only elements but also text() nodes as well in it's iterator inside the
submit() method in Submission. Then I used normal DOM API calls to create
new text nodes and insert them into the new relevancy-checked document that
is created as part of the selectRelevant() method call. This mean that I
turned off doing a setValue() for leaf items in the selectRelevant() method
since the value is handled using the text() nodes now.
well done. i'll write a test for it later.
Anyway.....attached is my "fixed" version of Submission.java, in case you
want to include it in 0.9.3 as a workaround till the JXPath guys can provide
an API that does the same thing.
i'll have a detailed look on it later when writing a test. just for now:
i think the expression path better has to be constructed the following way
expressionPath = expressionPath + "descendant-or-self::*|" +
expressionPath + "descendant-or-self::*/text()";
in order to select only text nodes below 'expressionPath'.
I tested it with the help.xml file and with my complex letter generation
application and it seems to work fine.
Hope this helps!
when it works fine it will be included in the release. ain't that good
news ?
regards, uli.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
------------------------------------------------------------------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: Submission.java
Date: 15 Oct 2003, 18:58
Size: 20862 bytes.
Type: Unknown
--
Ulrich Nicolas Lissé
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
|
Try Searching:
servers, voip, java, networking, microsoft ...
|
|
|
| 
