Showing posts with label Search. Show all posts
Showing posts with label Search. Show all posts

Tuesday, March 19, 2013

Set the HTML form with data from in the page's address


Use JQuery to fill in a Web form when post-back to the page using method="get".

Assume the a Web page has the following address http://localhost:/Example01.htm and contains the following simple HTML form:


The source code of that form may appear as following:

<form action="Example01.htm" method="get">

  <input id="QueryString" type="text" name="QueryString" />

  <select id="Method" name="Method">
    <option value="And">All Words</option>
    <option value="Or">Any Word</option>
  </select>

  <input type="submit" value="Submit" />

</form> 


Upon submit of the form, which references the current page in the forms action parameter, the page's address is updated with the values from the QueryString and Method input fields:

http://localhost:/Example01.htm?QueryString=my+query+terms&Method=And

The following JavaScript parses the address parameters to re-set the form with the data provided by the user:



<script src="jquery-1.9.1.min.js" type="text/javascript"></script>

<script language="javascript" type="text/javascript">


$(document).ready(function () {

    var vQueryString = getURLParam("QueryString");
    $("#QueryString").val(vQueryString);

    var vMethod = getURLParam("Method");
   $("select#Method option").each(function () {
 if ($(this).val() == vMethod) {
     $(this).prop('selected', true);
 }
    });

});

function getURLParam(name){
 return decodeURIComponent((new RegExp('[?|&]' +
    name + '=' + '([^&;]+?)(&|#|;|$)').exec(location.search) || 
    [, ""])[1].replace(/\+/g, '%20')) || null;
}
</script>

Tuesday, April 24, 2012

FAST ESP 5.3 - change the index location

Steps to move the FAST ESP v5.3 index to another drive or path. This was tested with the FSIA version of FAST but should be applicable to other implementations.

Note that AFAIK the drive and path must be consistent between all index/search nodes (due to rtssearchrc) and data_fixml and data_index still have to be on the same drive (which is a shame).

A. Stop all indexer and search processes on all nodes.

B. On Admin node, edit the webcluster file:

  1. \esp\etc\config_data\RTSearch\webcluster\rtsearchrc.xml
Change the $RTROOT variable to a hard coded path in
  •     fixmlPath="E:\esp\data\data_fixml"
  •     indexDir="E:\esp\data\data_index"
C. On EACH of the index and or search nodes update the following two files:
  1. \esp\etc\searchrc-1.xml
  • indexpath= "E:\esp\data\data_index"
  1. \esp\etc\rtsplatformrc.xml
  • indexDir = "E:\esp\data\data_index"
  • fixmlDir = "E:\esp\data\data_fixml"
D. Restart indexer and search processes.

Wednesday, December 9, 2009

Enterprise Search User Group

The user group aims to provide valuable and timely information to its members so as to foster the Microsoft Enterprise Search community’s growth locally in New York and worldwide via live broadcast presentations and recorded sessions. Its primary goal is to provide the opportunity and platform for otherwise disparate practices and business groups, to come together and share thoughts, ideas, successes and failures, in order to raise the bar - to increase quality across the board and grow a borderless body of knowledge. For details, please see: http://www.sharepointgroups.org/enterprisesearch/About.aspx

Wednesday, October 8, 2008

Missing standard for minimum URL length.

Applications differ on their support for the length of a URL because the specification fails to indicate any requirement for a minimum length (http://www.w3.org/Addressing/URL/url-spec.txt). MS Internet Explorer, for example, only support 2046 characters in it’s address box, a fraction of what other contemporary browsers will support. The Microsoft .NET Hyperlink component supports a much shorter URL, silently truncating the address, and Office applications and desktop shortcuts will fail to recognize links of even a moderate size.

The impact of this missing standard is that URLs with complex queries cannot be constructed or used reliably by many applications.

While there are design alternatives, such as using POST to send data to a server based session, any design choice that does not maintain the explicit page state in the URL will likely confuse users. That is, users expect that if they bookmark a page, they can come back to that page, even after a server side session has expired, and it will render identically. Other web paradigms include using the Web browsers back button to undo an action, something that .NET and AJAX applications frequently fail at since they tend to not update the URL when updating the page state. For a demonstration of this, observe how even MS’s Live.com site maintains page state in the URL rather then use the .NET paradigm of post backs to the server.

While maintaining page state in the URL is desirable the inconsistency of support for URL lengths ensures the design will, in some case or another, fail. The failure may happen in such a way that the user is unaware of the failure –as when additional query parameters are truncated and the resulting page is not as expected. For example, a query that contains key=foo+AND+bar” and is truncated to key=foo would likely result in a silent failure.

To defend against these silent failures a Web application must be designed to test for a truncated URL. How this is done depends upon the application. For example, in one application a special character or keyword may be is placed at the end of an applications URL if it contains a query. In another, the query includes a parameter for URL length that is tested for.

The key is that is that the pages URL cannot be assumed to be valid unless there is a test for validity.