Sorry, slip of keyboard meant I posted last message
mid-edit.
Hi Chris,
Thanks for taking the time to review this.
> 1) I aplaud the plugable nature of your solution.
I think that's definitely a worthwhile objective.
> 2) Digging into what was involved in writting an
> ObjectBuilder, I found...
> don't really feel like
> the API has a very clean seperation from SAX.
True. The efforts to remove state management were
entirely around the hand-off between one ObjectBuilder
and any "child" Object Builders - ie thinking of the
processing chain like the cartoon where one big fish
is about to eat a smaller fish, which is about to
eat a smaller fish which.... etc. The parser handles
the
stack of individual ObjectBuilders and their
consumption thus relieving one level of SAX-based
state management that a "just one big fish" approach
to parsing would take.
However within each individual ObjectBuilder they have
responsibility for handling SAX apis to configure
themselves. My assumption was SAX would be a
familiar/useful API but I guess that may be wrong.
> I think that the ideal API wouldn't require people
> writing ObjectBuilders
> to know anything about sax, or to ever need to
> import anything from
> org.xml.** or javax.xml.**
Fair enough. I presume we want to maintain the
position that Lucene should not have any dependencies
other than JDK1.4?
I did look at Commons Digester but that seemed to want
to suck in logging, beanutils etc so embarked on my
own lightweight SAX-based implementation.
>
> 3) While the *need* to maintaing/pass state
> information should be avoided.
> I can definitely think of uses for this framework
> that may *want* to pass
> state information -- both down to the ObjectBuilders
> that get used in
> inner nodes, as well as up to wrapping nodes, and
> there doesn't seem to be
> an easy way to that.
State "passed down" is something I saw as a potential
addition to the "Parser" object shared by all
ObjectBuilders eg a Map that was associated with
stack level.
> The best example i can give is if someone (ie: me)
> wanted to use this
> framework to allow boolean queries to be written
> like this...
>
> <BooleanQuery>
> <TermQuery occurs="mustNot" field="contents"
> value="mustNot"/>
> <UserInput occurs="must">"a phrase"
> fuzzy~</UserInput>
> </BooleanQuery
I did consider that my earlier version of BooleanQuery
could
be simplified to:
<BooleanQuery>
<MustNot><TermQuery field="contents" value="foo"/>
</MustNot>
<Must><UserInput>"a phrase" fuzzy~</UserInput>
</Must>
</BooleanQuery>
Although the "occurs" info could be set in the child
object as in your example that pushes some parsing
responsibility down into child elements and I feel
slightly uncomfortable about that as a technique. It
introduces the potential for nameclashes when mixing
various object builders and complicates documentation.
Its the same uncomfortable feeling I get from multiple
inheritance.
> Going the ooposite direction, I'd like to be able
> to have tags that set state which is accesible to
descendent >tags
Seems entirely reasonable. - See earlier comments
about Parser Stack.
I'll spend some time studying your psuedo code in more
detail later.
Cheers,
Mark
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
