X-Git-Url: http://git.indexdata.com/?a=blobdiff_plain;f=doc%2Fmkws-manual.markdown;h=c868b5a3b5454772c493c31b7764f203797be7c2;hb=b428fb16fd8706b18cace0031e85fd1d0b1e4ea5;hp=a315a22979efea4a1fbb910b09bea0923bf2b5ef;hpb=fda7da00419e8b5fdd051505c1073affa9690ae2;p=mkws-moved-to-github.git diff --git a/doc/mkws-manual.markdown b/doc/mkws-manual.markdown index a315a22..c868b5a 100644 --- a/doc/mkws-manual.markdown +++ b/doc/mkws-manual.markdown @@ -150,7 +150,8 @@ To see all of these working together, just put them all into the HTML
The full set of supported widgets is described in the -reference guide below. +reference guide +[below](#widgets). Widget team ----------- @@ -212,7 +213,7 @@ the English), initially sorts search results by title rather than relevance (though as always this can be changed in the UI) and makes the search box a bit wider than the default. -The full set of supported configuration items is described in the +The full set of supported configuration settings is described in the reference guide below. Per-widget configuration @@ -220,7 +221,7 @@ Per-widget configuration In addition to the global configuration provided by the `mkws_config` object, individual widgets' behaviour can be configured by providing -configuration items as attributed on their HTML elements. For example, +configuration settings as attributes on their HTML elements. For example, a `records` widget might be restricted to displaying no more than three records by setting the `numrecs` parameter as follows: @@ -237,11 +238,11 @@ attributes prefixed with `data-mkws-`, so: For first form is more convenient; the second is more correct. -Because some configuration items take structured values rather than +Because some configuration settings take structured values rather than simple strings, they cannot be directly provided by inline attributes. To allow for this, the special attribute `data-mkws-config`, if provided, is parsed as JSON and its key-value -pairs set as configuration items for the widget in question. For +pairs used as configuration settings for the widget in question. For example, the value of `lang_options` is an array of strings specifying which of the supported UI languages should be made available. The following invocation will limit this list to only English and Danish @@ -266,7 +267,7 @@ etc., customised layouts may wish to treat each of these components separately. In this case, `mkws-results` can be omitted, and the following lower-level widgets provided instead: -* `mkws-termlists` -- provides the facets +* `mkws-facets` -- provides the facets * `mkws-ranking` -- provides the options for how records are sorted and how many are included on each page of results. @@ -560,36 +561,42 @@ its own User Access record. When credential-based authentication is in use (username and password), it's necessary to pass these credentials into the Service Proxy when establishing the session. This is done -by setting the `sp_auth_credentials` configuration item to a string +by providing the `sp_auth_credentials` configuration setting as a string containing the username and password separated by a slash: mkws_config = { sp_auth_credentials: "mike/swordfish" }; ### (Optional): conceal credentials from HTML source -Using a credential-based Service-Proxy authentication URL such as the -one above reveals the the credentials to public view -- to anyone who -does View Source on the MKWS application. This may be acceptable for -some libraries, but is intolerable for those which provide -authenticated access to subscription resources. - -In these circumstances, a more elaborate approach is necessary. The -idea is to make a URL local to the customer that is used for -authentication onto the Service Proxy, hiding the credentials in a -local rewrite rule. Then local mechanisms can be used to limit access -to that local authentication URL. Here is one way to do it when +Using credential-based authentication settings such as those above +reveals the the credentials to public view -- to anyone who does View +Source on the MKWS application. This may be acceptable for some +libraries, but is intolerable for those which provide authenticated +access to subscription resources. + +In these circumstances, a different approach is +necessary. Referer-based or IP-based authentication may be +appropriate. But if these are not possible, then a more elaborate +approach can be used to hide the credentials in a web-server +configuration that is not visible to users. + +The idea is to make a Service Proxy authentication URL local to the +customer, hiding the credentials in a rewrite rule in the local +web-server's configuration. Then local mechanisms can be used to limit +access to that local authentication URL. Here is one way to do it when Apache2 is the application's web-server, which we will call -yourname.com: +yourname.com`: Step 1: add a rewriting authentication alias to the configuration: RewriteEngine on - RewriteRule /spauth/ http://sp-mkws.indexdata.com/service-proxy/?command=auth&action=check,login&username=U&password=PW [P] + RewriteRule /spauth/ http://sp-mkws.indexdata.com/service-proxy/\ + ?command=auth&action=check,login&username=U&password=PW [P] -Step 2: set the MKWS configuration item `service_proxy_auth` to - +Step 2: set the MKWS configuration setting `service_proxy_auth` to +`http://yourname.com/spauth/`. -Step 3: protect access to the local path +Step 3: protect access to the local path `http://yourname.com/spauth/` (e.g. using a `.htaccess` file). @@ -632,102 +639,448 @@ attribute as follows: Reference guide =============== -Configuration object --------------------- +Widgets +------- -The configuration object `mkws_config` may be created before including -the MKWS JavaScript code to modify default behaviour. This structure -is a key-value lookup table, whose entries are described in the table -below. All entries are optional, but if specified must be given values -of the specified type. If ommitted, each setting takes the indicated -default value; long default values are in footnotes to keep the table -reasonably narrow. +The following widgets are provided in the core set. (Others can be +added: see the [MKWS developers' guide](mkws-developer.html).) ---- -Element Type Default Description --------- ----- --------- ------------ -log_level int 1 Level of debugging output to emit. 0 = none, 1 = messages, 2 = messages with - datestamps, 3 = messages with datestamps and stack-traces. - -facets array *Note 1* Ordered list of names of facets to display. Supported facet names are - `xtargets`, `subject` and `author`. - -lang string en Code of the default language to display the UI in. Supported language codes are `en` = - English, `de` = German, `da` = Danish, and whatever additional languages are configured - using `language_*` entries (see below). - -lang_options array [] A list of the languages to offer as options. If empty (the default), then all - configured languages are listed. - -language_* hash Support for any number of languages can be added by providing entries whose name is - `language_` followed by the code of the language. See the separate section below for - details. - -pazpar2_url string *Note 2* The URL used to access the metasearch middleware. This service must be configured to - provide search results, facets, etc. It may be either unmediated or Pazpar2 the - MasterKey Service Proxy, which mediates access to an underlying Pazpar2 instance. In - the latter case, `service_proxy_auth` must be provided. - -perpage_default string 20 The initial value for the number of records to show on each page. - -perpage_options array *Note 3* A list of candidate page sizes. Users can choose between these to determine how many - records are displayed on each page of results. +Name Description +---- ----------- +`auth-name` Initially empty, it updates itself to shows the name + of the library that the application is logged in as + when authentication is complete. + +`builder` A button which, when pressed, analyses the current + settings of the team that it is a part of, and + generates the HTML for an auto-searching element + that will replicate the present search. This HTML is + displayed in an alert box: it is intended that this + widget be subclassed to store the generated widget + definitions in more useful places. + +`button` The search button. Usually generated a `search` + widget. + +`categories` Obtains from the Service Proxy a list of the target + categories associated with the library in use, and + displays them in a drop-down list. When a category + is selected, searches are limited to the targets + that are part of that category. + +`config` This widget has no functionality of its own, but its + configuration is copied up into its team, allowing + it to affect other widgets in the team. This is the + only way to set configuration settings at the team + level. + +`console-builder` Like the `builder` widget, but emits the generated + HTML on the JavaScript console. This exists to + provide an example of how to subclass the `builder` + widget. + +`cover-art` Displays cover art for a book by searching in + Amazon. Often used with an `autosearch` attribute to + indicate what book to display. For example, + `
` + displays cover art for _All Yesterdays: Unique and + Speculative Views of Dinosaurs and Other Prehistoric + Animals_. + For this widget to work, a library that includes the + AmazonBooks target must be used. For example, the + "DEMO AmazonBooks for MKWS" account, which can be + selected with `sp_auth_credentials="mkws-amazon/mkws"`. + +`details` This widget is generated by the toolkit itself to + hold the full details of records that are initially + listed in summary form. + +`done` Initially empty, this widget is set to display + "Search complete: found _n_ records" when all + targets have completed their work, either returning + a hit-count or an error. The message displayed can + be changed by overriding the `done` template using + `