> However, that being said, if the component does not
> care about changes to settings during parsing, then
> it does not need to "listen" to changes sent to the
> setFeature/Property methods. In other words, the
> component may query the value of the settings before
> parsing (in the reset method) and then ignore any
> changes that may occur afterwards (as communicated
> by the setFeature/Property methods). These would be
> settings that are not allowed (by the component) to
> change.
Thank you for your clarification. But I'm still bit puzzled.
If I read the following straightly,
> Components are managed by a component manager. The
> component manager keeps track of the parser state
> for features and properties. The component manager
> is responsible for notifying each component when
> the value of those features and properties change.
I get an impression that I can effectively ignore the reset method and
just rely on the setProperty method, since for any feature/property,
it is saying that the manager is responsible for notifying changes to me.
(assuming that "notifying each component" means "invoking setProperty")
But you are saying that the setProperty method won't be called for
changes between parsing.
So I think my question still stands. For any given property (be it
SymbolTable, ErrorHandler or what not), is there any way to know whether
I should be prepared for it to be changed during parsing or not?
You wrote:
> However, that being said, if the component does not care
> about changes to settings during parsing,
But it doesn't seem like a decision up to each component. Whether a
property can be changed during parsing or not is up to the definition of
the property. Therefore, to write a well-behaving component, I think I
need to find out this behavior for each property. (and hence my original
question)
By the way, why a component manager does not notify components of
property changes between parsing? If only it does, then I can just
implement setProperty and ignore the reset method. Easier to write.
This is just a feedback from an external component developer, so just
take it as such.
> > Is there any reason why constants are defined in the way they are
> > today?
>
> Yes.
>
> By defining the prefix separate from the feature or
> property identifier, you can write code such as:
>
> if (featureId.startsWith(Constants.XERCES_FEATURE_PREFIX)) {
> String feature =
> featureId.substring(Constants.XERCES_FEATURE_PREFIX.length());
> if (feature.equals(XXX_YYY_ZZZ_FEATURE)) {
> // do something
> }
> }
>
> If you don't like that style, then you don't have
> to use it.
I see. Then I think I'm going to ask if it makes sense for the full form
of the property name (PREFIX+PROPERTY) to be defined as well as the
short form (just PROPERTY).
As I wrote, 12 different classes are defining 12 different constants of
the same string. (And I'm just picking up this property randomly and I'm
not trying to show the worst example here.) It seems like a lot of waste.
Or is there any reason why the full form should not be defined as
a constant?
regards,
----------------------
Kohsuke Kawaguchi
E-Mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
