[EMAIL PROTECTED] wrote:
> Guess I assigned wrong meaning to XMLComponent. :-) There are only two
> methods defined on it, to get features/properties. So I thought an
XMLComponent has *five* methods: getRecognizedFeatures,
getRecognizedProperties, reset, setFeature, and setProperty.
The majority of the methods are present so that the manager
can pass settings to the configurable component. However,
XMLComponentManager has two methods for querying settings.
> XMLComponent is just an object within a certain environment
> (features/properties) and does some certain thing(s); while an
> XMLComponentManager is another object that provides such environment. So an
That is correct.
> > parseGrammar(XMLInputSource source, GrammarPool pool):Grammar
>
> We seemed to have agreed to make the grammar pool a public property on the
> parser. (Right?) Then I think it's better to treat it the same way here, so
I don't know if we agreed on this but it can certainly work
that way. Okay, so let's keep the "parseGrammar" method as:
parseGrammar(XMLInputSource source):Grammar
> > interface Grammar *
> > ...
> > * Should this really be called "XMLGrammar"?
>
> I would think. Everything in XNI seems to start with XML.
Well, not everything (e.g. QName, Augmentations, etc...). I
don't have a problem with either way.
> > And the implementation *might* be something like this:
> >
> > package org.apache.xerces.util
> > class XMLGrammarCache implements XMLGrammarPool,
> > XMLComponentManager
>
> I still don't understand why we need this XMLGrammarCache (which is
> responsible for loading different kind of grammars) to implement
>From the name alone, it doesn't say that its job is to
load different kinds of grammars. "Cache" is simply "pool";
I could very easily just call it "XMLGrammarPoolImpl". My
point was that it would be useful (as a convenience) to
have a way of registering grammar loader instances and
pre-loading grammars into the cache.
Remember, XMLGrammarCache does not apply to the *design*
of the xni.grammars package; it's an implementation detail
for Xerces2 (and other people that want to use its generic
ability to cache grammars).
> But grammar loaders are deep in the impl package, and are not intended to
> be used directly, so we introduce a util class so that the user can
> XMLGrammarSOMETHING loader = new XMLGrammarSOMETHING();
> XMLGrammar grammar = loader.loadGrammar
> ("http://www.w3.org/2001/XMLSchema";, input);
I didn't want to bother with a factory interface for
querying a grammar loader of a specific type. And one of
the reasons why it doesn't make sense right now is that
we haven't defined what an "xyz" grammar looks like. Aside
from our extremely simple Grammar interface, the actual
implementations are tied directly tied to their associated
validator implementations.
> I don't see why XMLGrammarSOMETHING needs to implement XMLGrammarPool. Of
> course a grammar pool is useful, but it can always be passed to the loader
> by setting a property.
I hope that I didn't give you that impression. I never
meant to say or imply that XYZGrammar implements the
grammar pool interface.
> > I try not to use constructors to set state for objects
> > unless those objects are immutable.
>
> Aren't constructors for initialization purposes? I think giving an object
> the initial state *should* happen in the constructor. The state of this
Passing values in the constructor as the only way to set an
object's state makes it extremely limited in its usefulness.
Especially in a dynamic language like Java. Think of JavaBeans
or other component architectures.
> util class is a list of grammar loaders, and the constructor sets it to the
> initial state: putting two loaders in the list. I don't see why it's not
> proper.
Then we'll just have to agree to disagree.
> > I don't why it requires the grammar cache to be a component
> > and a component manager.
>
> It needs to be a component because it needs to know about the features and
> properties (and forward them to grammar loaders). It needs to be a
> component manager because I thought it should implement XMLComponentManager
> (to manager grammar loaders), which, of course, is not a must now.
It certainly *can* but I was just making the point that one
does not necessarilly imply the other.
> Another way is to use the loaders directly, because each validator knows
> which loader to use. Then the validators would be responsible for
> forwarding features/properties to the loaders, or the loaders can implement
> XMLComponent, so that they can be updated by the configuration. But I don't
> see how a validator can add an component to the configuration.
I agree. Just like the way that all of the components require
a SymbolTable but none of them create it -- that's the job of
the parser configuration. Same thing here.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
