[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RFC: Simple XML Event-Based API for Java
>I don't see the point of the XmlProcessor first argument. What's wrong >with having the implementation of XmlApplication store the XmlProcessor >in the member variable? (This is what SP typically does.) XmlApplication can not store the XmlProcessor in the member variable because it is an interface. I am very happy to see that XmlProcessor and XmlApplication are interfaces rather than classes. Of course, it would help to have some sort of Factory or Manager. >The one major omission I see here is absense of information about the >location (URL, byte offset, line number etc) of the events. It would be >very nice to be able to implement validation as just as an >XmlApplication (that wraps around another XmlApp). In others to to run >without validation you would use: This is exactly why I proposed XmlFilter. XmlValidator derived from XmlFilter can be used to add validation at runtime. Each class and interfaces should have a clearly intended role. Stringing XmlApplications along like some kind of Unix app is not something I would like to see people do. I would rather see folks developing XmlFilters to be intentionally used as converters or by-product producers. >> On the positive side, this interface would let you hang more than one >> application off the same parse, which could be very interesting. > >I don't think this is a good idea. It adds complexity and it's likely >to impose a performance cost, but it doesn't buy you anything, because >you can achieve that functionality with a MultipleXmlApplication class >that implements the XmlApplication interface, and provides >addApplication and removeApplication methods, and then forwards each >event to the applications that have been added to it. Support of multiple event listeners is the norm in the Java world. As they say "When in Texas, wear cowboy boots". I have no concern about performance cost since Java loops are not very expensive compared to method invocations and object instantiations. If we were really concerned about performance, I would recommend giving up the use of String. Pool of marker/cursor into a string buffer will improve performance by a factor. >> userData property also gives users a chance to pass extra information >> to the processor easily, if they wish. >Surely there are cleaner ways to do this sort of thing. I do not think so. Just as every Mac developer loved having RefCon to hang thing onto, I like userData. Could I have get/setStudData methods?;-) Don xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|