Basic Search Implementation

Question

Can anyone suggest how Basic Search is implemented through Adaptive Tags in WCI.
Or is there any way how to show basic search settnigs in community page.

Answer 1

Found this article in my saved files, I think it's what you're looking for. It's for 5.0 Portal, but I suspect it works with later releases as well.
5.0 Search Results Page URL Format (DA_223496)
Print Page
Article ID: DA_223496 Article Type: INFO
Created: Mon, Apr 19, 2004 Updated: Mon, Apr 19, 2004
Summary
This article provides instructions on how to build a portal URL that runs a search with a given set of constraints.
More Information
This article describes how to construct a portal URL that runs a search and displays results on the portal's search results page. For example, an HTML form that includes a search box would also include these parameters (most of which would be hidden inputs in the form).
Step 1: Required parameters for all searches
Start constructing any search URL with these parameters:
Parameter
Value
Explanation
in_hi_space
SearchResult
Tells the portal to create a new SearchResult ActivitySpace.
in_hi_spaceID
<integer>
(UI Framework parameter) Leave this off the initial search URL. Links on the result page include this parameter so that the portal framework can reuse a cached ActivitySpace.
in_hi_control
searchstart
Use this on the initial search URL to indicate that it is, indeed, an initial search.
cached
false
(UI Framework parameter) Tells the portal not to reuse any previous SearchResult space. Include this on the initial search URL.
parentid
<integer>
(UI Framework parameter) The spaceID of the ActivitySpace that launched the search. Not used by the search code.
in_hi_userid
<integer>
(UI Framework parameter) Current user’s ID. Not used by the search code.
Step 2: Indicate the type of query you want to run
The initial search URL needs to specify a search query. After the user views the initial page of results, links or controls on the page let the user modify the query (for example, go to the second page) or add additional queries (“search within results” or category drill-down).
There are two types of initial query you can run:
Basic search: Specify a search string. Also, optionally, specify object types, folders, and such via URL parameters. You cannot restrict the search by the value of an arbitrary portal property. Only the properties listed on the "Banner Fields Alias" page of the Search Results Manager are searched (this list is usually Name, Description, and Full-Text Content).
Advanced search: Offers all the flexibility of the portal’s advanced search page. Specify a complete PTFilter in URL parameters: some settings might come from user form inputs, while others might come from hidden parameters. You can also specify object types, folders, and such via URL parameters.
Banner search is a special case of basic search in which certain settings (the object types to be searched) are preset by the portal. The portal uses the special value in_hi_control=bannerstart to distinguish banner search from an ordinary basic search. Ordinarily you should use in_hi_control=searchstart unless you want the special banner search behavior.
The URL parameters for basic and advanced search differ slightly.
To run a basic search use just one required parameter:
Parameter
Value
Explanation
in_tx_query
<string>
The user’s search string.
Advanced search has a long list of possible parameters. (If you do not need to constrain by property values, just use basic search and skip to the next step.)
Looking at the Filter Editor or Snapshot Query Editor in the portal will make the following table clearer. An advanced search query is the same as a filter (except for the optional settings shown in Step 3 below). There is a top-level text search string, which matches items’ name, description, or full-text content (like basic search). There is also a tree of property constraints; each grouping (or clause) in the tree consists of a set of statements, which in turn consist of a property ID, an operator (such as “contains”), and a value to match against.
The easiest way to proceed might be to build the search on the Advanced Search page or in the Snapshot Query Editor, then click through to the search page (from Advanced Search or the Content Snapshot portlet). Save the initial search result page URL and compare it with the parameters below.
Parameter
Value
Explanation
in_ra_topoperator
and or or
This is a required parameter for advanced search. Indicates whether the top-level text search string and the entire property constraint tree will be joined by an AND or an OR (corresponding to “all criteria” or “any criterion” on the advanced search page). If the text search string is empty or there is no property tree, this operator is unimportant, but the parameter must still be included.
in_tx_fulltext
<string>
The top-level text search string. Can be empty.
in_hi_totalgroups
<integer>
Number of groups (clauses) in the property constraint tree. (This is not the depth of the tree, since there could be more than one clause at a given depth.) This is always 1 for a search constructed on the Advanced Search page, since the page does not allow nested clauses.
in_ra_groupoperator_j
and or or
Boolean operator that joins statements in group j (first group is 1, not 0). For searches constructed on the Advanced Search page, there is always just one such parameter with j=1, and it is the same as in_ra_topoperator.
in_hi_revealed_j
<integer>
Number of statements in group j. Must be at least 1.
in_hi_depth_j
<integer>
Depth of clause j in the tree. For group 1 (the single group you can build on the Advanced Search page) this is 0. In general, if clause j has depth d, then clause j’s parent is the last clause to be specified with depth d-1. This means that you need to number the clauses depth-first, not breadth-first.
Example: If group 1 has depth 0, group 2 has depth 1, group 3 has depth 2, group 4 had depth 1, and group 5 has depth 2, then 1 is the parent of 2 and 4, and 2 is the parent of 3, and 4 is the parent of 5.
in_se_PropSelect_j_k
<integer>
ID of property being constrained by statement k of group j (the first statement of any group is 1, not 0), followed by a bar (|) character, and a single-digit code indicating the type of the property (which should match the property definition in the portal – this is inconvenient). The code is 3 for long, 5 for double, 7 for date, 8 for string.
in_se_OpText_j_k
<integer>
If statement k of group j constrains a text property, this is the operator (from PT_FILTEROPS) that joins the property ID and value. For example, 7 is “contains”.
in_se_OpNumber_j_k
<integer>
Same as preceding, except used for numeric properties. 1 is “equals”, 2 is “not equals”, 3 is “less than”, 4 is “greater than”, 5 is “less than or equal to”, 6 is “greater than or equal to”.
in_se_OpDate_j_k
<integer>
Same as preceding, except used for date properties. 3 is “comes before”, 4 is “comes after”.
in_tx_compareval_j_k
<string> or <double>
For statement k of group j, the comparison value. If the property being constrained is of type date, use the next item instead.
in_tx_comparedate_j_k
<long>
For statement k of group j, the comparison value if the property being constrained is of type date, expressed as the number of milliseconds since 1/1/1970 00:00:00.
Step 3: Add optional settings to the search
Finally, for either a basic or advanced search, you can use any of the parameters listed in the following table to restrict the search as described. This list does not include restrictions by portal property values; to do this you must use an advanced search.
These arguments must be preceded by a prefix. You can generally use in_hi_req_ in all cases, but refer to the text after the table for other options.
Parameter
Value
Explanation
prefix + lang
2-letter language code
Language that query is parsed in. Default is the user’s current language setting.
prefix + lbl
1 for true, 0 for false
Limit By Language. If true, results must be in the same language used to parse the query. Default is true.
prefix + apps
1 for portal, 2 for Collab, 4 for Content
Plumtree application to search. You can combine applications by bitwise-ORing the values, for example, 3 for “portal or collab”. Default is whatever applications are installed.
prefix + objtype
Any value from PT_CLASSIDS, such as 18 for cards
Portal object types to search for. Repeat multiple times to search for multiple types. You cannot restrict the types of Collaboration Server or Content Server items using URL parameters; all you can do is turn them on or off with the apps setting.
prefix + ddfolder
<integer>
ID of Knowledge Directory folder to search. Repeat this argument multiple times to search multiple folders.
prefix + adfolder
<integer>
ID of Administrative Object Directory folder to search. Repeat this argument multiple times to search multiple folders. If ddfolder and adfolder are both included, items from either the Knowledge Directory or Administrative Object Directory can be returned.
prefix + subfolders
1 for true, 0 for false
If true, subfolders of any folder specified by ddfolder or adfolder are included as well. Default is true.
prefix + community
<integer>
ID of community to search.
prefix + spell
1 for true, 0 for false
If true, use the Search Server’s spell correction capabilities to try to find matches for any terms it does not recognize.
prefix + bbs
1 for true, 0 for false
If true, and if the query string matches a Best Bet trigger string, rank the Best Bet’s targets at the top of the result list. Applies only to basic search, not advanced search.
prefix + thesaurus
1 for true, 0 for false
If true, use the Search Server’s thesaurus to expand the query string(s).
prefix + portletid
<integer>
For Content Server items (only), restricts the search to items associated with the supplied portlet ID.
A note on prefixes: As stated above, ordinarily you can prefix any of these arguments with in_hi_req_ and things will be fine. However, the portal UI framework sometimes forces checkboxes and radio buttons to have names starting with in_cb or in_ra, so you can also use in_cb_req_ or in_ra_req_ in those cases.
Also, the prefix in_hi_opt_, in combination with the in_se_sel_ family of arguments, lets you add drop-down selectors to search forms that cause conditional behavior depending on the selected item. The rule is:
If any parameter starting with in_se_sel_ appears, take its value (call it V).
Look for any other parameters starting with in_hi_opt_V_, where V is the value you just located. Apply those settings to the search (using the above table) in addition to any in_hi_req_ prefixed settings.
See the examples below.
Examples
Here is a search form that implements very basic search for portal documents:
<form method="post" action="http://portal.plumtree.com/portal/server.pt">
<input type="hidden" name="in_hi_space" value="SearchResult"/>
<input type="hidden" name="in_hi_control" value="searchstart"/>
<input type="hidden" name="cached" value="false"/>
<input type="hidden" name="in_hi_req_apps" value="1"/>
<input type="hidden" name="in_hi_req_objtype" value="18"/>
Search: <input type="text" name="in_tx_query"/>
<input type="submit" value=">>"/>
</form>
Here is a search form that implements an advanced search for portal documents. It displays two search boxes. One matches text in the name, description, or content of the document, and the other matches the Author property. In addition, the Keywords property is implicitly constrained to contain the text ‘plumtree’.
<form method="post" action="http://portal.plumtree.com/portal/server.pt">
<input type="hidden" name="in_hi_space" value="SearchResult"/>
<input type="hidden" name="in_hi_control" value="searchstart"/>
<input type="hidden" name="cached" value="false"/>
<input type="hidden" name="in_hi_req_apps" value="1"/>
<input type="hidden" name="in_hi_req_objtype" value="18"/>
Search for: <input type="text" name="in_tx_fulltext"/>
<input type="hidden" name="in_ra_topoperator" value="and"/>
<input type="hidden" name="in_hi_totalgroups" value="1"/>
<input type="hidden" name="in_ra_groupoperator_1" value="and"/>
<input type="hidden" name="in_hi_revealed_1" value="2"/>
<input type="hidden" name="in_hi_depth_1" value="0"/>
<!-- "and Author contains.." -->
<!-- Author is property 103 -->
<input type="hidden" name="in_se_PropSelect_1_1" value="103|8"/>
<input type="hidden" name="in_se_OpText_1_1" value="7"/>
where the Author contains <input type="text" name="in_tx_compareval_1_1"/>
<!-- "and Keywords contains plumtree" -->
<!-- Keywords is property 101 -->
<input type="hidden" name="in_se_PropSelect_1_2" value="101|8"/>
<input type="hidden" name="in_se_OpText_1_2" value="7"/>
<input type="hidden" name="in_tx_compareval_1_2" value="plumtree"/>
<input type="submit" value=">>"/>
</form>
Here is an example of using drop-down selectors in a search form. It is a bit contrived, but this form gives the users the option of searching “Marketing” (documents under folder 123), “Sales” (documents under folder 456), “Communities” (search for any community the user has access to), or “Collab projects” (items within Collaboration Server projects).
<form method="get" action="http://portal.plumtree.com/portal/server.pt">
<input type="hidden" name="in_hi_space" value="SearchResult"/>
<input type="hidden" name="in_hi_control" value="searchstart"/>
<input type="hidden" name="cached" value="false"/>
<!-- if Marketing is selected, search folder 123 for documents -->
<input type="hidden" name="in_hi_opt_marketing_apps" value="1"/>
<input type="hidden" name="in_hi_opt_marketing_objtype" value="18"/>
<input type="hidden" name="in_hi_opt_marketing_ddfolder" value="123"/>
<!-- if Sales is selected, search folder 456 for documents -->
<input type="hidden" name="in_hi_opt_sales_apps" value="1"/>
<input type="hidden" name="in_hi_opt_sales_objtype" value="18"/>
<input type="hidden" name="in_hi_opt_sales_ddfolder" value="456"/>
<!-- if Communities is selected, search for communities, anywhere -->
<input type="hidden" name="in_hi_opt_communities_apps" value="1"/>
<input type="hidden" name="in_hi_opt_communities_objtype" value="512"/>
<!-- if Collab is selected, search for anything in Collab -->
<input type="hidden" name="in_hi_opt_collab_apps" value="2"/>
Search..
<select name="in_se_sel_1">
<option value="marketing">Marketing folder</option>
<option value="sales">Sales folder</option>
<option value="communities">All communities</option>
<option value="collab">All Collab projects</option>
</select>
for: <input type="text" name="in_tx_query"/>
<input type="submit" value=">>"/>
</form>
The information in this article is related to:
Foundation (Portal) versions: 5.0.x
Search Server versions: 5.0
Other Products:
Topics: Search
Related Articles: 5.0 Search Results Page
Search Syntax in Plumtree Corporate Portal
Keywords: search,customization,link,clickthrough,url parameters