Erik's scenario pretty much nails it for me.
I prefer the Ant-like XML approach over a Spring one because all the
messy classnames are removed from document instances. ( I wasn't
suggesting we use either technology, merely citing them as object
assembly languages). Haven't seen HiveMind/Digester - will have to take
a look.
>>Because of the variations in how the Query subclass constructors and
setters work, there will need to be a little bit of glue between as
well, I presume.
Yes, I imagine objects with zero arg constructors and public getters and
setters are required to represent query requests if the same parser is
to work with new query types.
Another nice-to-have would be for all the existing Query objects to be
persistable in the new format. So if I use the existing query parser or
the existing Java API directly I can always persist and retrieve the
query, all settings intact. This is like what the current
Query.toString() tries to do but falls short of because of limitations
in the existing query syntax.
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
