Aleksander Slominski wrote: > wouldnt it be better to throw an exceptionif user tries to set > features that are not allowed in this state of the parser?
You're absolutely right -- someone just needs to implement it. I'm waiting for your patches. :) > it just took me a bit of time to figure out why XNI was > forgetting my settings... A long time ago I considered this problem in regards to making it work in a general parser configuration. Currently we have methods like getRecognizedFeatures/Properties that returns an array of strings that represent the feature/ property identifiers. This works fine but it would be nice if there was also some way of report other attributes of features/properties like the following: * is feature/property read-only? write-only? read-write? * is there a difference between before parsing and during? I spent acouple years doing components like JavaBeans so I guess I tend to think in terms of some kind of BeanInfo objects that tell you more information. A similar solution could be used for parser configuration features and properties. Perhaps I'm just over-thinking the problem. And maybe it's not the components job to tell the parser configuration how it should handle these kinds of cases. I mean, it really should be the parser configuration that decides which features and properties are allowed to be set before and during a parse. But should we add something to XNI? And if so, what? -- Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
