Steven Dolg wrote: > Carsten Ziegeler schrieb: >> Wouldn't it be better/easier to have a sax pipeline, a dom pipeline, a >> stax pipeline, perhaps sharing a common interface? >> > From my point of view: > Currently the user must know which components he needs (as in "I want to > process XML and I'd like to do it with StAX"). > As soon as he know this, he just selects the components (either existing > or created) but them in *any* pipeline (caching/noncaching/etc.) But the user needs to choose the same xml transportation for all components in the pipeline, being it directly or through wrappers.
> If there were multiple, content-specific Pipelines he still needs to > know which components, but also which type of Pipeline. > If he feels the need to change to SAX (so a switch in the "event type" - > IMO a sub-optimal term, since not every component actually passes nice > events like StAX does) he also needs to change the Pipeline. > This may seem easy now, but imagine a larger system. Changing the > pipeline type can be challenging there. >From what I understand so far in this discussion this simple switching does not work (or is not intended to be implemented - which is fine for me). So besides from switching the pipeline implementation you have to switch all components or at least add matching wrappers around them. > And what about automatically generated pipelines (e.g. the sitemap). > This will be so much harder as you have to collect and analyze all > components first before you can actually build the pipeline to use. I think you have to do this anyway - as not all components fit together. > Defining a common interface for different pipeline types does not really > change this. > If the common interface is sufficient for handling and operating the > pipeline they are exchangable (from the callers point of view) and > provide the same environment we have now. > If the common interface is not sufficient for handling and operating the > pipeline it is merely a marker interface and it probably wouldn't make > much difference. (Although it is still useful for declaring parameter > types, etc.) > > > I may be biased here ;-) but I have yet to see the benefits of different > pipeline types... :) I have the same feeling for the opposite...if I can't just mix dom with sax and maybe stax, then why following this generic approach? Hmm, maybe generics could help? So we have something like: public interface Pipeline<T extends PipelineComponent> and have sub interfaces for PipelineComponent for sax, dom, stax? This ensures to have a single implementation but gives compiler time checks. Carsten -- Carsten Ziegeler [email protected]
