Mircea Toma wrote: > > Hi, > > From: "Carsten Ziegeler" <[EMAIL PROTECTED]> > > > ....My personal opinion would have been to > > > rename the interfaces to SAXParser and DOMParser to avoid > having to use > > > fully qualified classnames because of the same name. > > > > > Yes, I thought of that, too - and wanted to do it today. (To be precise, > > it wasn't me that started this splitting, but that's not important). > > ;) > > When I did the refactoring I thought about this a lot. In my opinion there > is no need for a DOMParser at all. Most of the DOM parsers base > their lexing > functionality on a SAX parser and use a DOM builder after that to > create the > XML structure in memory. In our case the Parser interface is doing the > lexing while the DOMHandler is responsible for creating the DOM structure. > You can see this as a SoC pattern or you can see it as an inefficient > pattern :) Good suggestion ;) - Ok, I tend to the second opinion... It is not very user friendly to lookup two components to parse something into a DOM. So I think, a DOMParser has a certain value.
> Yes, the current DOMHandler implementation is using JAXP classes to do the > transformation but that's just because I'm lazy.... > > > > Also, wouldn't it make sense to move the default implementations to a > > > separate package? > > I does if the implementation has a bunch of classes that can be > grouped in a > package (with the package name based on the specific > implementation). But if > the implementation is just one class then I don't see any harm in > having 2-3 > (usually) implementations in the same package with the service interface. > I created the package yesterday and moved the Jaxp and the Xerces implementation into it. We *can* (if we want) split the implementation, so that we really have one DOM implementation for Jaxp and one SAX implementation for Jaxp and so on. I'm not sure which way is better. Carsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
