: This example code looks interesting. If I understand
: correctly using this approach requires that builders
: like the "q" QueryObjectBuilder instance must be
: explicitly registered with each and every builder that
: consumes its type of output eg BQOB and FQOB. An
correct.
: provider for the class (Query) at runtime. I presume
: doing it your way is a deliberate design choice in
: order to validate at compile time that a particular
: parser configuration has all of the necessary builders
: in place to support incoming XML. That seems like a
err... more to validate at compile time that some Builder which
wraps another Builder isn't expecting the inner builder to return a Query
when the inner builder is garunteed to only ever return a Filter. the
situation might still come up where the incoming XML doesn't match the
expectation of hte code, at which point the inner builder can say "i don't
have the attributes/data i need to construct an object, so i'm throwing an
exception"
: reasonable approach.
: If I get some time I'll look at implementing something
: based on this.
two other things about an approach like this that occured to me while
i was trying to sleep are:
1) the Builder interfaces don't need to exactly mirror the object
hierarchy, in some cases what really makes sense is an interface per
"trait" so an interface like a "SloppyBuilder" can be implimented by the
PhraseQueryObjectBuilder and a SpanNearQueryObjectBuilder (which also
impliments SpannyBuilder) so builders that expect the nested XML they get
to contain stuff that has slop can require you register a SloppyBuilder
with them.
2) requiring that each builder be explicitly passed a refrence to a
builder of each type it wants to know about is a pain .. and it might be a
dangerous pain if you're trying to "replace" one builder with another one
-- ie: consider the case where a default set of builders exists, and you
ant to replace all uses of PhraseQuery with a SpanNearQuery ... you
remember to replace/override the delegation in QueryBuilder .. but maybe
there's some other Builder that wraps PhraseQuery's you forgot about.
A static pointer could be stored in the interface itself, so that if you
want to redifine the builder that gets used when you want a
"SloppyBuilder" you just access SloppyBuilder.INSTANCE....
public interface QueryBuilder extends ObjectBuilder {
public static QueryBuilder INSTANCE;
public Query process(Node n);
}
public interface SloppyBuilder extends QueryBuilder {
public static SloppyBuilder INSTANCE;
}
... but that requires a single set of registered ObjectBuilders per JVM,
so i'm not fond of the idea ... but perhaps the someone can think of a way
that the same overall concept could be applied in a more general way.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
