Hi,
I think I'm just a little late with this feedback, but here goes...
>At the moment I propose two interfaces to add search capability to turbine.
>This is a first draft and I would appreciate any comments and suggestions.
>It is not a service yet, but will probably be after some issues have been
>resolved. These include the issue of how to implement pooling of connections
>to the search engine. Maybe a generic pool class :-).
<general object naming rules>
Naming matters for long-term maintainability and for design clarity.
Name a class a noun (i.e. what is the *thing* to which the attributes and
methods apply?).
An abstract class or particularly an interface may be named an adjective
(i.e. Serializable) because its sense is combined with the derived class
or the implementing class to make an adjective-modified noun.
i.e. SearchEngine or SearchableRepository or even Searchable
are preferrable over Search (a verb)
When you are tempted to name the class a verb or a general concept,
that may be good name for the package, but not for the class.
i.e. org.apache.turbine.search is a fine package name
Search (a verb) is not a great class name
Name the method a verb, and the class name should be a suitable object
for the verb in a sentence.
i.e. put() is a fine method name, but that would imply you were
"putting a SearchEngine" (which is not the intent).
In fact, what you are putting is a search criterion
(and "set" might be better verb than "put"). (I know, you
are modelling this after other classes already in Turbine.
Precedent is almost as strong a motivator in naming as any
other standard of "correctness".)
i.e. connect() => good. ("connect to a SearchEngine")
put() => setSearchCriterion() ("set a search criterion for the
engine")
get() => getSearchCriterion() ("get a search criterion from the
engine")
doSearch() => search() ("search a SearchEngine")
(doSearch is a really bad name, revealing that
you have in fact named the class after a verb)
(I know I am a day late and a dollar short to influence
all
of the updates with doBuild() and doPerform().)
</general object naming rules>
Anyway, this is just a general soapbox.
What I really want to communicate is that there's a lot of great
code being built on Turbine and I and everyone else appreciate it.
If these naming guidelines help anyone, then so be it.
Stephen
>// First interface to access a search engine:
>public interface Search
>{
> // Open a connection to the search engine
> public boolean connect (String username, String password);
>
> // Select the library to search (most search engines have the concept
> // of "libraries" of indexed stuff, e.g. the server's hd in library 1,
> // the app's db in library 2, etc.)
> public boolean setLibrary (String library);
>
> // Get & Set any variables that are specific to a search engine
> // The wrapper could declare the "names" of these variables as static
> // final Strings. One could also use a Criteria kind of class that gets
> // passed in here with all necessary variables (e.g. searchterms,
> // numofresults, fuzzyspellingstyle, etc.)
> public void put (String name, String value);
> public String get (String name);
>
> // Does the search for a user query
> // The type of searches available will depend on the
> // underlying search engine: default = 0 (Types could include
> // boolean, concept, fuzzy, etc.)
> public boolean doSearch (String query, int type);
>
> // Get an enumeration of SearchResult (see next interface)
> public Enumeration getResults();
>}
>
>
>public interface SearchResult {
>
> // Get the field names that is available for this result
> public Enumeration getFields();
>
> // Get a value for a given field name
> public String get (String fieldname);
>}
>
>Regards
>Leon
>
>
>
>
>------------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
