[XalanJ2] Proposal for ordered ElemTemplateElement iterator

[Scott Boag/CAM/Lotus <Sc...@lotus.com>]

I think we need to globally solve the issue with included top-level
elements, a bit beyond just what we've done for templates.  For instance,
the results of recomposeOutput will be incorrect in certain circumstances.
Also, the general pattern in recomposeDecimalFormats, recomposeOutput ,
recomposeKeys, etc., is brittle, problematic, hard to maintain, and
contributes to large code footprint.

I am thinking of a TemplateElemIterator class that takes a
StylesheetComposed as a constructor argument, and an TemplateElemAccessor
interface that would have a getElement(int i) method and a getElementCount
() method.  It would have the usual getNext and getPrevious methods.  The
TemplateElemAccessor would normally be constructed as an anonymous class.
The iteration would be defined to iterate over the elements and included
elements in document order. It would be interesting to try and have this
cover both included and imported stylesheets, but handling the imported is
a bit tricky since the semantics change at that level.  Maybe
getImportNumber and getComposedStylesheet methods would do the trick.

Gary, Myriam, do you understand what I am proposing, and do you think that
this change would be a good thing at this stage in the game?

-scott

Re: [XalanJ2] Proposal for ordered ElemTemplateElement iterator

[Gary L Peskin <ga...@firstech.com>]

Scott Boag/CAM/Lotus wrote:
> 
> I think we need to globally solve the issue with included top-level
> elements, a bit beyond just what we've done for templates.  For instance,
> the results of recomposeOutput will be incorrect in certain circumstances.
> Also, the general pattern in recomposeDecimalFormats, recomposeOutput ,
> recomposeKeys, etc., is brittle, problematic, hard to maintain, and
> contributes to large code footprint.
> 
> I am thinking of a TemplateElemIterator class that takes a
> StylesheetComposed as a constructor argument, and an TemplateElemAccessor
> interface that would have a getElement(int i) method and a getElementCount
> () method.  It would have the usual getNext and getPrevious methods.  The
> TemplateElemAccessor would normally be constructed as an anonymous class.
> The iteration would be defined to iterate over the elements and included
> elements in document order. It would be interesting to try and have this
> cover both included and imported stylesheets, but handling the imported is
> a bit tricky since the semantics change at that level.  Maybe
> getImportNumber and getComposedStylesheet methods would do the trick.
> 
> Gary, Myriam, do you understand what I am proposing, and do you think that
> this change would be a good thing at this stage in the game?

I'm sure I don't understand this 100% but, in principle, I think this is
a good idea.  With the information that we have now, we should be able
to construct an Iterator that would traverse the elements in the proper
order.  I don't understand where the TemplateElemAccessor fits in. 
Would this act as a filter to only select certain elements or what?

It might be nice to have a structure where you just iterate over all of
the ElemTemplateElements in order and then fire a method based on the
type of ElemTemplateElement you're currently at.  This way, you could
compose things as you go and make one pass over the composed elements. 
Sort of a SAX-type approach.  Is this what you were thinking?

I do think this change would be good at this stage.  The composition
processing is very confusing and a uniform approach in one place would
be better than the logic that is currently repeated in every recompose
method.

So, I say go for it.  If you want to hash out further details in the
list, feel free.  Otherwise, I'll see your ideas in code and go from
there.

Gary