Paul Sandoz <[EMAIL PROTECTED]> writes:
> >> *
> >> */
> >> attribute long match;
> >
> >So is this attribute necessary because you need to know how to sort
> >the list of returned matches? It seems like it would be a bit clearer
> >to call this "type" or "matchType".
> >
>
> No its not about sorting its about how an item would be
> compared (or 'matched') against an instance.
>
> e.g. Match 'first name' which CONTAINS 'paul'
> Match 'email' with REGEXP '^d.*@.*\.org$'
> Match <property name> <match<Type?>> <property value>
>
> I originally called it 'matchType', changed it, changed it back
> and re-changed it! Basically i am not sure.
Ah, ok. The current addressbook autocomplete code tries a whole bunch
of different match types that are internally hardcoded. I like your
strategy of making them parameterizable though. For the current LDAP
autocomplete, my intent is to make it be parameterizable, but I
haven't really sorted out the details of exactly how yet. In part,
this is because the LDAP autocomplete piece is likely to continue to
be useful outside of addressbook (eg if someone wanted to write a
bugzilla XUL front-end, they could use it there too).
> >> interface nsIAbDirectoryQuery
> >> {
> >> // ? Do we need supported match
> >> // ? types
> >
> >It seems like it; this is something that folks might want to specify
> >via a preference.
> >
>
> Hmm.. maybe its more to do with what an implemention
> supports e.g. some implemetations may not support
> regexp match so its not a user preference.
That's true, but it may also be relevant to have as a preference. EG
for small LDAP directories, doing a soundex match may be reasonable,
but for enormous ones, it might not.
> >> // ? Do we need a parameter to control
> >> // ? how sub-directories are queried
> >
> >I guess that depends on the UI you wish to provide. Is there some
> >case where you might not want sub directories searched?
> >
>
> I was thinking that the query interface could be used to
> get child cards in an asynchronous manner, we know
> when all have been received because the query result
> will tell us. This is a response to the fact the the
> nsIAbDirectory.getChildCards could be implemented
> asychronously notifying RDF indirectly making it
> impossible to know when all the cards have been
> recieved.
Couldn't you just have the query code assert a "querycompleted"
property into the RDF datasource when it's done? Then the absence or
presence of that property would be enough to know.
> >> /**
> >> * Initiates a query on a directory and
> >> * sub-directories for properties on cards
> >> *
> >> * @param matchProperties
> >> * The properties and values to match
> >> * Value could of type nsIAbDirectoryQueryMatchItem
> >> * for matches other than ?contains?
> >> * @param matchItems
> >> * Defines how multiple match items should
> >> * be treated for a query result
> >> * Match one or more
> >> * Match all
> >> * @param returnProperties
> >> * The properties that will be returned that
> >> * result in a query result
> >> * ? Can this be represented as an array of strings
> >> * ? instead
> >
> >Yes, it can. And it would be nicer to folks accessing this interfaces
> >from languages other than C++. An example of how to do it is at
> >http://lxr.mozilla.org/seamonkey/source/xpcom/threads/nsIProcess.idl
> >
>
> Yep. Ah!, i would also like the possibility to return
> other types like nsIAbCard.
>
> Hmm... perhaps two methods are required. One for strings
> and the other for more detailed information using the
> nsIProperties interface.
Conceivably, although it's worth noting that you can return an array
of interfaces to JS just like you would return an array of strings.
So maybe dropping the strings method would be ok too.
> >> * @param nsIAbDirectoryQueryResultListener
> >> * The listener which will obtain individual
> >> * query results
> >> * @param resultLimit
> >> * No more than 'limit' results will be returned
> >> */
> >> void doQuery (in nsIProperties searchProperties,
> >> in long matchItems,
> >> in nsISupportsArray returnProperties,
> >> in nsIAbDirectoryQueryResultListener,
> >> in long resultLimit);
> >> };
> >>
> >
> >Should there be a "max number of hits to return" parameter here too?
> >
>
> Not sure i understand. I think that:
> _
> "max number of hits to return" = resultLimit
>
> i.e. i don't understand the difference.
Oh; heh. I must have had a brain-fart. Never mind. :-)
> >> interface nsIAbDirectoryQueryResultListener
> >> {
> >> /**
> >> * Called when a match is found. May be
> >> * called from a different thread to the
> >> * one that initiates the query
> >> *
> >> * @param result
> >> * A individual result associated returned
> >> * from a query
> >> */
> >> void onQueryItem (in nsIAbDirectoryQueryResult result);
> >> };
> >>
> >> interface nsIAbDirectoryQueryResult
> >> {
> >> // ? Do we need to have the attributes
> >> // ? associated with the query here
> >> // ? i.e. parameters passed on the doQuery method
> >
> >I suspect that the answer to this will become more clear as you get
> >deeper into the coding.
> >
>
> Just had a thought; some context may be required
> if multiple queries are performed using the same
> listener object.
Yes, this seems likely. In fact, after I came up with the design for
the LDAP datasource in JavaScript, I realized that it probably can't
be written in C++ using the LDAP XPCOM wrapper as it now stands. The
datasource keeps track of multiple queries by using the fact the JS
functions are lexically closed to bind the original query to the
callback. At some point, we'll probably need to add "nsISupports
aContext" args to various methods in the XPCOM wrapper so that it can
support this model from C++.
Dan
--
