On 28 Dec 2007, at 10:16, Paul Fremantle wrote:
The purpose of TextFileDataSource is actually to implement a text
node
(+ <text> wrapper element) that is backed by a temporary file rather
than a String/char[] object, thereby avoiding to load the entire file
into memory. Maybe we should consider another solution that avoids
the
problems described above. The idea would be to use a custom
implementation of OMText (that again is backed by a temporary
file). I
think that if the custom implementation extends OMNodeImpl and
implements OMText, an instance can be added to the Axiom tree without
problem, given that the Axiom code never casts OMText to OMTextImpl.
An alternative (but less clean) solution would be to extend
OMTextImpl.
I agree these would work, but I'm not sure why this would be better
than fixing up the DataSource model. The DataSource approach was
designed to solve the problem of creating new forms of data-backed
OMNodes. If it isn't working well enough we should raise this issue
with the axiom dev team.
The main argument in favor of the custom OMText solution was
simplicity. There is however another solution that is a bit more
complicated but that strictly adheres to the OMDataSource model. The
idea is as follows. What TextFileDataSource does is to construct an
InputStream that represents the concatenation <text> + text + </text>.
It then uses this input stream to build an XMLStreamReader. The
problem comes from the fact that "text" is plain text, not XML text. A
quick fix could be to wrap the text in a CDATA section (i.e. <text><!
[CDATA[ + text + ]]></text>), but this doesn't solve the character
encoding problem. A better solution is then to implement a custom
XMLStreamReader that synthesizes the following sequence of events:
* START_DOCUMENT
* START_ELEMENT
* (CHARACTERS)*n
* END_ELEMENT
* END_DOCUMENT
Since the output of XMLStreamReader for the CHARACTER events is pure
character data, we don't need to care about XML entities and character
encoding at that level.
To summarize, the solution would be to replace the custom InputStream
implementation by a custom XMLStreamReader implementation. This
XMLStreamReader implementation would have more or less the same
complexity as the existing InputStream implementation.
Regards,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
