: > A) generate an XML representation of a given
: > Query/Filter object. This would solve the current
: > parser.parse(Query.toString())round-tripping problem.
:
: This would be very useful, but couldn't it be added after this was in
: contrib? You might reorganize things so that it fits in more cleanly.
: For example, you might rename the builder interface to be something
: that encompasses externalization also, so that you can easily later add
: an externalize(Query) method to the interface and all of its
: implementations.
I would argue that the existing interface names are fine -- but the
concrete class names should probably be changed to not explicilty mention
"Builder". Down the road, "Formater" interfaces can be defined, ie...
public interface QueryFormater {
public Element formatQuery(Query q);
}
public interface FilterFormater {
public Element formatFilter(Filter q);
}
...and if it makes sense for the existing classes to start implimenting
them they can, but clients that want to write their own Queries (and their
own Builders for those Queries) don't have to worry about implimenting a
format method unless they care about it that functionality.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
