[
Lists Home |
Date Index |
Thread Index
]
- From: Leigh Dodds <ldodds@ingenta.com>
- To: Miles Sabin <msabin@cromwellmedia.co.uk>
- Date: Thu, 13 Jan 2000 14:30:36 -0000
Miles Sabin wrote:
> An XMLReaderFactory could return an Iterator or Enumeration over
> the available implementation classes (more likely over some
> meta-information providing access to the features of the
> various installed parsers so an application can choose if
> there's more than one) and allow an app to select and
> instantiate one.
Why not have the Factory method accept the criteria,
and return an implementation directly, rather than forcing
the application to iterate over them?
In the case where there are several parsers with the same
properties, it will either matter to the application - in which the
preference will be hard-coded (not good) as it will have to select
it from the list, or it won't matter, so returning the
first match is good enough.
If there are two parsers with the exact same features its likely
that there will be other differentiators which can't be
checked in code. e.g. which is the fastest.
> The neat thing about this is that if we choose a well known
> location on the CLASSPATH to put the provider files it'll be
> possible to bundle a parser implementation along with it's
> own provider file.
Why not have the equivalent of a BeanInfo file for the parser.
Just add the package names to the XMLReaderFactory's property
files and the properties can be checked at runtime. This
seems less complex. Loading and parsing a file seems like more
overhead than instantiating a BeanInfo equivalent and querying
it directly.
Anyway, doesn't the JAXP package address some of these issues?
http://web2.java.sun.com/xml/download.html
Cheers,
L.
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.
|
