Basic Search Portlet

Hi
We are using the basic search portlet as the search engine within the MOHE portal page. When we search for any word which exists in a clipped html file it returns nothing.
Regards
Mohamed Hammed

Hi Mohamed,
I am not sure it would work....here's why -
If you consider the archtitecture of a WebClipping Portlet, the "definition" ( basically, the MetaData) is constant / static for every instance. However, the content generated by the WebClipping Portlet - i.e, the "clipping" - is dynamic & occurs at runtime. Hence, every WebClipping Portlet "Instance" generates it's own content - however, the Basic Search Portlet can't search the content generated by this instance.
I hope I was able to articulate that to a resonably good degree. Well, a suggestion that I can think of is to develop a custom search Portlet - something that could search the HTML text after all the Portlets have been rendered. I guess you can try with a Java Servlet....
Regards,
Sandeep

Similar Messages

  • How to change the view of the basic search portlet

    Hi,
    I want to change the view of the basic search portlet. To be more precise, I just want a text box and a Go button in it. Cananybody advise on how to do this?
    Regards,
    Priya

    Indeed the 'Basic Search Box' item is what you want to use. You can choose what label you want or an icon if desired.
    As mentioned in a previous reply, you need to edit the properties of the Page Group where you want to add the item and add the 'Basic Search box' to the list of available items that a user can add to the page group.
    Navigator -> Properties (for the desired page group) -> Configure Tab -> Edit link in the 'Content Type and Classification' section -> Item Types section add the 'Basic Search Box'.
    Now in a page in that page group, add an item, and from the list of 'Built-In Navigation Item Types' you will see the 'Basic Search Box'.

  • Basic Search portlet returns error when Display in New Browser Window set

    Ora AS Portal 10G release 2 (10.1.2.x)
    Have a region of type Portlets.
    The enable users to include content in this region is enabled.
    I added a Basic Search Portlet in this region.
    Basic search works fine if launched from current area, however if change attributes of region to have a link that displays item in new browzer window, then
    basic search portlet opens in new browzer window but returns error "Error: You do not have permission to perform this operation. (WWC-44131)"
    The Basic search portlet in the new window contains a link to advanced search. If use advanced search, results are returned.
    to test further, I added a advanced search portlet to this region, also with the display option to display item in a new window. In this case, the same error is obtained when doing a search.
    Has anyone experienced this?
    Any solutions?
    Thks in advance.
    Paulo

    Hi,
    Can you clarify what you mean by "change attributes of region to have a link that displays item in new browzer window"?
    Are you referring to Edit Region > Attributes tab ? Which of the Available Attributes did you select?
    Thanks,
    Chris

  • Error on Basic search portlet in Oracle portal

    I am working on Oracle 10g portal. I uploaded lot of documents and completed indexing as per Oracle guidelines. There are some errors during indexing.Out of 5000 documents 22 are not indexed. When I try to search from a page I get this error. This problem doesn't exist in our development environent where there are only few documents loaded. I have encountered errors in this environment also during index creation.
    Appreciate your help.
    Internal error (WWC-00006)
    An unexpected error has occurred (WWS-32100)
    Unknown Exception (WWC-45131)
    User-Defined Exception (WWV-11230)
    Unexpected error - ORA-20000: Oracle Text error:
    DRG-10599: column is not indexed (WWC-35000)
    ----------------

    Hi,
    What errors did you get during indexing?
    -Ron

  • Customizing the basic search

    hi all
    is there a way to fully customize the basic search portlet? how can i change the name of the "search" button - i want it to be in my native language, and the portal doens have a translation for it
    can anyone help?

    this is the code of my custom search portlet
    Hope it help you
    <table cellSpacing="0" cellPadding="0" border="0" id="table1">
    <FORM ACTION="http://oasserver2.mici.gob.pa/portal/page?_pageid=6,9553&_dad=portal&_schema=PORTAL" METHOD="POST" NAME="mysearchform" onSubmit="fetch();" style=margin:0;>
      <tr>
              <td>
              <input class="textA" id="Search"  size="22" name="ms" style="font-family: Arial; font-size: 10px; color: #3A5B9E">
              </td>
              <td>
              <p align="right">
              <a onclick="javascript: return isNotNull(document.searchForm.keyword.value)" href="javascript:document.searchForm.submit()" style="color: #000; text-decoration: none">
              <input type="image" src="http://oasserver2.mici.gob.pa/img/search.jpg" border="0" alt="Submit" width="21" vspace="1" border="0">
              </tr>
    <INPUT TYPE="hidden" NAME="pg" VALUE="40">
    <INPUT TYPE="hidden" NAME="search_type" VALUE="Simple">
    <INPUT TYPE="hidden" NAME="ll" VALUE="">
    <INPUT TYPE="hidden" NAME="p_action" VALUE="SUBMIT">
    <INPUT TYPE="hidden" NAME="_dad" VALUE="portal">
    <INPUT TYPE="hidden" NAME="_schema" VALUE="PORTAL">
    </FORM>
    </table>

  • How to use p_mainsearch parameter in basic search for a report with bind variable?

    Hello,
    I'd like to extend the basic-search in content-area elements to extra records in my own tables.
    So I'd like to use the p_mainsearch-urlparameter (which holds the searchtext of a basic search) into a bind variable of my own report. My report will be on an extra tab on the search-page.
    Especially I don't know how to transfer the value of p_mainsearch into the bind variable of the report.
    Has anyone done that so far?
    Example?
    Thank you,
    Joerg

    I found out the following way:
    1.)Report
    1.1)SQL-Query:
    select * from <owner>.<tablename> where UPPER(column) like '%'||UPPER(NVL(:searchtext,'abczyx123098'))||'%'
    (Note: bind variable is :searchtext).
    1.2)in "before displaying page"-section in "additional plsql" add the following:
    if length(get_value('p_mainsearch')) >= 3 then
    portal30.wwv_name_value.replace_value(
    l_arg_names, l_arg_values, p_reference_path||'.searchtext,
    portal30.wwv_standard_util.string_to_table2(get_value('p_mainsearch')));
    end if;
    1.3) publish as portlet
    2.) Integrate the report-portlet into a new tab on search page. Run basic search.
    Change to the tab with the portlet.
    For me it is solved.
    Joerg.

  • How to create a custom search portlet that groups results by category

    Hello,
    Is it possible to create a custom search portlet whose search results are displayed on a page grouped by Category? Basically the results page should have Category heading followed by search results.
    I realize this is not canned functionality but any ideas on how to accomplish this using PLSQL APIs is also welcome.
    Thanks.

    hi,
    one workaround i could think of is using the CM views to search for content that belongs to a category and display it in a custom way.
    http://www.oracle.com/technology/products/ias/portal/html/plsqldoc/pldoc904/wwsbr_api_view.html
    this only allows you to search for the meta-data available in the CM views but not the content of an item that is available when doing a search.
    in the next major portal release we will have a publich search API that can be used for these type of requirements. you can execute your search and format the results in the way you want.
    regards,
    christian

  • Basic Search not working in 9iAS release 2

    gurus,
    the basic search is not working in 9iAS Release 2.
    i created few items in the portal and searched for values in basic search ... it did not return any search results ... i checked the search settings and found the Drop Index button ... thus i assumed that the indexes are created .... is there something wrong here ...?
    also, the client wants the search to return in a custom page .... how would i achieve that .... is there an api that i could call in form action and render the search output in my custom page ....?
    any help would be appreciated ...
    thanx

    Have you run the job to update the indexes? Please refer to the Configuration Guide for instructions on synchronizing the indexes with your content.
    The default Search Results page is defined in the Global Settings, under the Administration tab on the Builder page. Any page can be used for search results, as long as it contains the Custom Search portlet.

  • Basic Search Item javascript error

    When I use the Basic Search Item to submit a search, I get a Javascript error:
    Error: 'document.mysearchform.p_looplink' is null or not an object
    Examining the page HTML shows that submitting the serach runs this function
    function fetch() {
    var purl;
    purl = location.href;
    document.mysearchform.p_looplink.value = purl;
    document.mysearchform.submit;
    but the form mysearchform doesn't have a field called p_looplink
    The form fields are
    INPUT TYPE="text" NAME="ms" SIZE="15" MAXLENGTH="30"
    INPUT TYPE="submit" VALUE="Go"
    INPUT TYPE="hidden" NAME="pg" VALUE="33"
    INPUT TYPE="hidden" NAME="search_type" VALUE="Simple"
    INPUT TYPE="hidden" NAME="ll" VALUE=""
    INPUT TYPE="hidden" NAME="p_action" VALUE="SUBMIT"
    INPUT TYPE="hidden" NAME="_dad" VALUE="portal"
    INPUT TYPE="hidden" NAME="_schema" VALUE="PORTAL"
    This bug only appears when you have your browser set to report all Javascript errors - it doesn't prevent the search from working.
    Any ideas about what's going on here?
    Does the basic Search Item (not the portlet) work properly for anyone else?
    Rob

    hi rob,
    this problem is reported in bug 3801639. it is fixed in portal 10.1.2.
    regards,
    christian

  • Basic Search with API

    Hallo,
    I use Portal 3.0.8.
    I made a portlet that uses the following command to do a basic search :
    portal30.wwsbr_search_api.submit_search (
    p_search_terms => p_string,
    p_search_operator => 'FIND_ANY',
    p_caid => r_get_ca.id,
    p_language => 'us',
    p_search_for_type => 'ALL_OBJECTS'
    p_string : a search string that the user entered in a field
    r_get_ca.id : the id of the content area where to search for
    But when I enter a search string in that field, the search utility returns a result screen without any hits. When looking at the default values he present for the next search, I see that every wanted parameter is correctly filled in. When I do the search again with this result screen, he found something. Where is the difference ?
    What do I have to change ?
    Thanks in advance.
    Filip Huysmans.

    Filip,
    did you manage to make it work?
    I want to try to use this API to develop a custom search screen.
    I am researching in the different forums to see other people experiences.
    Tks!

  • Basic Search Implementation

    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.

    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

  • Custom Search portlet : how to sort the result in sequence (Portal 10.1.4)

    With a Custom Search portlet how to Sort the Result By Sequence. i.e. by respecting arrangements of the items in the page of contents?
    Actually the Results Options "Order By" are : Create Date, Author, Creator, Date Updated, Display Name, Last Update by, Publish Date, Score.
    Is there an action to add the "Sequence" Order By result Option?
    Great thanks for your kind help.
    Best regards

    No, I agree that it is functionality that should be added to the product, but it
    is not a bug because it was not written to do this.
    It is a short coming of the product.
    Cheers,
    Ersan

  • Custom Search Portlet : Find all item created in a such year

    Hi,
    I'd like to find the way to search for items created in a such year.
    I have added the 'created on' attribute in the form, but the operator is equal lower of higher.
    What I need is to find the item created from 1st January to 31 December.
    Does anyone have an idea ?
    Benoit Pironet

    hi,
    this is the expected behavior. the way it is working is that the search portlet is going against the search index. in fact there are 2 search indexes on the server: one for the meta-data and one for the content. both indexes are craeated using oracle text. by default the indexer is refreshed every 1 hour due to performance reasons.
    if you want to change this you can do it - this is described in the portal configuration guide. you can also real-time synch your indexes. this is a new features in 10.1.4.
    http://download.oracle.com/docs/cd/B14099_18/portal.1014/b19305/cg_srch.htm#i1027594
    8.3.5.1 Synchronizing Oracle Text Indexes
    hope this helps.
    regards,
    christian

  • Basic Search Not working

    Hi,
    I'm playing around with the Basic Search Tutorial in the
    Dreamweaver CS23 Help files and i cannot seem to get it to work,
    even though I'm following it step by step.
    When I type in a word, that does exist the search Results
    page opens but the page is blank except for ht Dynamic table
    Headers.
    I'm specifying the GET function, but I have also tried Post
    but the same outcome.
    Testing the Recordset in the Search results page works fine.
    Anyone any hints here please?
    Using MySQL with Dreamweaver CS3
    cheers

    Figured it out. The Help files were misiing several key
    steps. I used a URL Variable to the mix and now the search
    works

  • Customizing L&F of Search Portlet

    By default, Portal adds a graphical and text link to "Content Area Home" to its search portlet. The design of our site is not supposed to include links to our content areas, but I haven't found a way to get rid of the link in the search portlet. Can anyone shed some light on how I can custimize the portlet in such a way? Thanks.

    Unfortunately, the search Portlets make extensive use of javascript, as do many other parts of the Portal product. There isn't a way of getting the search portlets to work without javascript. Neither is it easy to write your own portlet user interface to Portal Search at present.
    If you only wish to search public content you could consider using Oracle Ultra Search to crawl and search Portal. This provides java implemented sample search portlets. These may meet your requirements, or they could be used as the basis for your own Ultra Search portlets that don't use javascript.

Maybe you are looking for