> > Just in case you are wondering what are other solutions are:
> > 1) each component could implement setFeature, setProperty and get all
> > the properties and features. However, during
> > XMLComponent.reset() no features and properties will be queried.
> > I am not sure if XNI components were designed to be reset in such a
way,
> > and I suspect this approach might be a bit slower.
>
> I'm not quite following your explanation. Are you
> saying that each component would still be passed the
> component manager but that the component is smart
> enough to *not* query the settings that it got from
> the last parse? This seems fragile at best.
There seem to be 2 ways to pass features/properties to components: via
reset() method and via setFeature/Property() methods. Currently most Xerces
components rely on reset() to get feature/property values, which is the
reason why reset is so slow.
This alternative suggests that, for those components who care about
performance, they *could* ignore feature/property values when reset() is
called, and only pay attention to setFeature/Property() for the value
changes. (They will be slower than reset(), but the assumption here is that
people don't change feature/property values very often, so they won't be
called very often.)
The benefit is that this is only a change in the component implementation,
and doesn't require any XNI change. But there does exist a problem. There
are many features/properties whose values are not supposed to be changed
during a parse. The reset() method guarantees that, but
setFeature/Property() don't.
Just trying to clarify what this alternative means.
Thanks,
Sandy Gao
Software Developer, IBM Canada
(1-905) 413-3255
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
