Hi, Steven Dolg wrote: > Actually that is all we have right now. > Pipeline and PipelineComponent. With PipelineComponent being > differentiated into Starter, Finisher and Consumer/Producer - what you > called the "middle parts". (Actually there is still a design flaw: the > consumer is no PipelineComponent, but that'll be corrected presently). > Consumer and Producer are separated into two interfaces, as to not > require special handling when linking the Starter with the second > component or the second to last with the Finisher. > > I like to call these the "structural layer", because they define the > structure of any pipeline: > * first component is always a "Starter" > * last component is always a "Finisher" > * any number pairs of "Producer"/"Consumer" between them > > Every (valid) pipeline is composed in this way - regardless of what > content or which implementation. > > Thus these interfaces have no relation to anything that is content-based. > But that's also why we need additional layers, because otherwise the > pipeline would be specific for every type of content (which it should not) > I like the explaination :) Yes, it makes sense this way.
> All the XML... interfaces are already the "content layer" (in this case > for SAX) on top of the "strcutural layer" > It defines how the components communicate with each other: > 1. XMLConsumer is a ContentHandler and LexicalHandler > 2. XMLProducer can accept an XMLConsumer and provide it with > appropriate data > > Follow (basically) by AbstractXMLProducer (implementation of 2. from > above) and AbstractTransformer (AbstractXMLProducer + XMLConsumer). > The "content layer" is already beyond the scope of the Pipeline API > module - it does not care about this at all. > This is solely the domain of the pipeline components. > That's why the SAX layer should be removed asap from the Pipeline API. Yepp. > <SNIP/> > Absolutely! > With two types of XML components (SAX, StAX) this name is completely > ambiguous and must be changed (I prefer SaxConsumer). > > This would also emphasize that the Pipeline API is designed to be > content-agnostic and SAX is merely one type of content it can handle. > StAX is the first step to add another content-type - well it's still > XML, but works completely different. Yes. > Not at all - I usually welcome all input! > I just have a hard time, when I struggle to get the actual point. :) > > Trying to understand what you mean, I looked at some code and followed > the class/interface hierarchy. > And while doing so I found that some of this is rather strange and took > me moment to sort out. > And I think I know now what you mean. Yes, it's hard to explain (at least for me) :) > > But I guess it's mostly a problem with the names of the > classes/interfaces (like "AbstractTransformer" being actually an SAX > based Producer/Consumer) and mixing SAX with the Pipeline. > I suppose separating those two and changing some of the names it should > be alot better. Yes, I guess that's all we have to do. >> It's >> just about minor improvements if at all. > I think it's actually a little bit more than that. > Seems like I was already so accustomed to the concept in my head that I > didn't even see, the implementation has become less clear that it could be. This happens, but here we have the advantage of the community :) > So PLEASE keep on doing this! > And don't feel bad when my answers appear a little harsh - I rarely mean > it that way... ;-) No problem with that :) Carsten -- Carsten Ziegeler [email protected]
