Simon Kitching wrote:
<snip>
If the user finds their parser is not supported they doThat's a valid argument (This is exactly what I did in Tomcat)...but I think making life easier for the user is better, and hiding the XML schema complexity is a way to explore.
have a fallback: the options listed at the start of this email. These
options are just as simple as someone writing a separate Factory for
their parser type, and less baggage for Digester to be carrying around.
+1
(that's why i prodded JeanFrancois to come up with something like this :)
we've had a lot of issues with users digesting documents with schemas posted to the lists. yep, there are ways to solve them (and we should probably patch the documentation to tell users that they should probably be tuning their parsers direct) but many users want to be able to digest without knowing or caring about the parser they are using. (for example, me :)
there's also the issue of portability - digester is often used in web apps. the actual parser which will be used may be unknown when the web app is created. it'd be nice to support portability even if this means putting in parser specific code.
i think that the code is fine but i'd like to try to improve the structure. (i've had some bad experiences in the past with static utility classes in beanutils). i'd like to make it easy for developers to post easy patches supporting other parsers which we can easily plug in. but i'll need a little more time to think about this before i can come up with anything more concrete...
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
