--- Comment #5 from Mehdi Houshmand <med1...@gmail.com> 2011-04-15 04:40:37 EDT
> That might be an option. Store the char array, and later on, trigger
> characters() on the retrieve-marker, if appropriate.
> However, I believe it is not strictly necessary. Also, the current approach of
> constructing the FOText early and using clones later, has the convenient
> side-effect that the text nodes are stored in sequence with the rest of the
> marker's child nodes.
Well, I guess that would depend on how this was implemented. If we were being
puritanical, one could argue that if FOText was an object representation of
#PCDATA (which I'm pretty sure it is), then by creating a #PCDATA child in the
FOTree, we are creating an invalid node. Regardless of whether we address this
invalidation later or not, validation should be done before binding nodes to
the FOTree; invalid nodes shouldn't be bound to the FOTree in the first place.
One way to solve this, is by postponing the creation of the FOText while still
keeping the char array. This means that the data is kept, while we're
maintaining the validity of the FOTree. Though I appreciate, if we did this,
we'd have to maintain the rest of the current behaviour so as not to introduce
> Ultimately, FOText _is_ already basically just a CharBuffer with some extra
> The only real gain would be that the FOText property references can be
> so it might still be worthwhile to investigate, but more as a performance
You may be right, it might be prohibitively complex doing it the way I'm
suggesting. It'd have to be investigated, this this is less about a performance
enhancement since as you said, the creation of an FOText object is cheap.
> As I see it, what we definitely lack:
> - a good/decent way to detect if a FO can have text children; I do not
> particularly like 'instanceof FObjMixed', since that does not cover possible
> extension classes that subclass FObj directly
> - (more general) proper validation of the marker's immediate children against
> the parent of the retrieve-marker
Yeah I agree, I was disinclined to use "instanceof FObjMixed".
Thanks for the assistance, but I think we're going to avoid the "quick fix".
We've been bitten by them before.
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.