4 Replies Latest reply: Feb 28, 2012 9:21 AM by Guest RSS

Search keywords in custom property renderer?

Currently Being Moderated

Hello,

 

I'm writing a property renderer and I want to get the search term that the user entered.

 

How do i accomplish that?

 

Is there a special piece of code needed to retrieve the search keyword from the search frontend?

 

I have tried this code:

-schnipp-

ISearchSession searchSession = proxy.getSearchSession();

IQueryEntryList queryEntryList = searchSession.getQueryEntryList();

-schnapp-

but got an NullPointerException.

 

Thank you,

Ulrich Reichert

  • Re: Search keywords in custom property renderer?
    Detlev Beutner
    Currently Being Moderated

    Hi Ulrich,

     

    That was a tricky one.

     

    Decompile PropertyRendererHighlightedContentLink.class; the passed property (when called within a search result, of course) offers the search session id. Just fragments:

     

    String propertyValue = property.getStringValue();
    String values[] = StrUtil.decodeStrings(propertyValue);
    searchSessionMode = values<i>;
    searchSessionID = values[++i];

     

    Now decompile HighlightedContentControl.clas. Again, some fragments:

     

    com.sapportals.wcm.util.controlstatus.IControlStatus controlStatus = ControlStatusService.getInstance().getControlStatus(getSearchSessionID());
    searchSession = ((ISearchSessionProvider)controlStatus).getSearchSession();
    QueryEntryList queryList = searchSession.getQueryEntryList();

     

    With these results at hand, you should be able to create the rest...

     

    Hope it helps

    Detlev

    • Re: Search keywords in custom property renderer?
      Currently Being Moderated

      Hi Detlev,

       

      Thanks!

       

      I tried but got an NullpointerException on:

      property.getStringValue()

       

      Any ideas?

       

      Greetings,

      Ulrich

      • Re: Search keywords in custom property renderer?
        Detlev Beutner
        Currently Being Moderated

        Hi Ulrich,

         

        Indeed... This was even more tricky.

         

        The code stolen from the renderer expects that the value of the predefined property highlighted_contentlink is passed. In fact, this "property" does not "really" exist, but it is filled during a search; the property name "highlighted_contentlink" is hard coded, so this does not work for other properties, at least not directly...

         

        Anyhow, with a small trick this works nevertheless.

         

        You probably have created your own "dummy" property within the predefined properties, let's name it "searchexpression". You have set your own property renderer for this, called "search_expression". With this setting solely, it doesn't work, as there is no property "searchexpression" on the resource, so the passed property is empty.

         

        BUT: If you configure your own property with "Composed of" with "cm_rnd_highlighted_contentlink", it works! With this, when renderProperty of your renderer is called, the currentMetaName is "rnd:searchexpression", but the property passed is the "highlighted_contentlink", and so is it's value.

         

        That value has got the search session ID as one string parameter, which you extract and get the session.

         

        This is guaranteed now, as I have tested this (my first answer was blind theory by decompiling).

         

        This is somehow a workaround, but at least, it works. From the hard coded implementation for highlighted_contentlink I expect that there is also no more really elegant solution. Of course you could implement a non visible search component which puts the expression or whatever into the session, but at least this would need even more development and configuration (even if that approach wouldn't "misuse" some existing features).

         

        Hope it helps

        Detlev

         

        PS: Just realized a small flaw of the given approach: It only works if for the concrete search result a document extract is available. If not, the property won't be filled (now we see the disadvantage of "misusing" the property given, as it is meant for the highlighted content link, which only exists / gets rendered if a document extract is showable).

         

        So, if this flaw makes the solution useless, you probably really would have to store the search session, the search expression or whatever you want somewhere by storing it through the implementation of a non visible search component.

Actions