Autocompletion - Revision history

Th.lauke@arcor.de: typos corrected, links added, '== romeo ==' removed

2019-09-17T17:29:09Z

typos corrected, links added, '== romeo ==' removed

← Older revision		Revision as of 17:29, 17 September 2019
Line 3:		Line 3:
	For a how-to, please see [[Autocompletion and Authority Files (Romeo Autocomplete)]] or [[Adding an Auto-Completer to a non-workflow page]]		For a how-to, please see [[Autocompletion and Authority Files (Romeo Autocomplete)]] or [[Adding an Auto-Completer to a non-workflow page]]

	Autocompletion in EPrints 3 consists of ~~serveral~~ stages.		Autocompletion in EPrints 3 consists of several stages.

	* A field in the workflow is configured to say what autocompletion URL to use, plus any additional parameters to pass to the script. This URL must be on the same server (eg. foo.eprints.org) but does not have to be part of the EPrints system.		* A field in the workflow is configured to say what autocompletion URL to use, plus any additional parameters to pass to the script. This URL must be on the same server (e.g. foo.eprints.org) but does not have to be part of the EPrints system.
	* The autocomplete script takes the text typed so far (and maybe the additional parameters) and returns a chunk of XML describing possible autocomplete options. This XML consists of a number of rows (how many is up to the script).		* The autocomplete script takes the text typed so far (and maybe the additional parameters) and returns a chunk of XML describing possible autocomplete options. This XML consists of a number of rows (how many is up to the script).
	* Each row contains some HTML to show the person viewing plus a magic <nowiki><ul></nowiki> block which is hidden from display, but is used by the autocomplete ~~javascript~~ to autocomplete the page.		* Each row contains some HTML to show the person viewing plus a magic <nowiki><ul></nowiki> block which is hidden from display, but is used by the autocomplete JavaScript to autocomplete the page.

	== Autocomplete Scripts ==		== Autocomplete Scripts ==
Line 48:		Line 48:
	=== simple_file ===		=== simple_file ===

	File needs an additional parameter to be passed to it. This is configured in the workflow. This parameter is the name of a file in the cfg/~~autocompete~~ directory. This file contains a list of values which are searched (case insensitively) and matches returned. A second parameter of "mode=prefix" can be set to only match values which start with the text being typed, rather than contain it. Add a second and subsequent parameter by using a semi-colon ( ; ) as delimiter (tested in 3.3.10)		File needs an additional parameter to be passed to it. This is configured in the workflow. This parameter is the name of a file in the cfg/autocomplete directory. This file contains a list of values which are searched (case insensitively) and matches returned. A second parameter of "mode=prefix" can be set to only match values which start with the text being typed, rather than contain it. Add a second and subsequent parameter by using a semi-colon ( ; ) as delimiter (tested in 3.3.10)

	=== simple_sql ===		=== simple_sql ===
Line 54:		Line 54:
	Similar to simple_file but gets its values from a database table.		Similar to simple_file but gets its values from a database table.

	The table must be in the eprints database used by this repository and start with "ac_". The script needs a param. passed from workflow to indicate the name of the table WITHOUT the ac_ prefix. Eg. if the table was "ac_badgers" the parameter would be "table=badgers". The only field used is "value" which works like the lines in the text file. If you want this to be blindingly fast you can make sure "value" is indexed, and set mode=prefix. With those set autocompleting from a dictionary of half a million words worked cheerfully.		The table must be in the eprints database used by this repository and start with "ac_". The script needs a param. passed from workflow to indicate the name of the table WITHOUT the ac_ prefix. E.g. if the table was "ac_badgers" the parameter would be "table=badgers". The only field used is "value" which works like the lines in the text file. If you want this to be blindingly fast you can make sure "value" is indexed, and set mode=prefix. With those set autocompleting from a dictionary of half a million words worked cheerfully.

	~~=== romeo ===~~

	(not included in 3.0, expected in 3.1) This script uses the EPrints/Romeo data to provide journal autocomplete data. Should be attached to the publication field. This is almost identical to file, but inserts the required Powered by Sherpa note.

	=== url_name_value ===		=== url_name_value ===
Line 66:		Line 62:
	=== file ===		=== file ===

	This is for more complex autocompletion authority files. It works like simple_file except that the file format is more complicated.		This is for more complex autocompletion authority files. It works like simple_file except that the file format is more complicated. For a how-to, please see [https://wiki.eprints.org/w/Autocompletion_and_Authority_Files_(Romeo_Autocomplete)#Creating_Your_Own_Authority_File_.28complex.29 Autocompletion and Authority Files (Romeo Autocomplete)]

	The file consists of lines which contain:		The file consists of lines which contain:
	* a value to search, (eg. "African Journal of Agricultural Research")		* a value to search, (e.g. "African Journal of Agricultural Research")
	* a tab		* a tab
	* a <nowiki><li></nowiki> autocomplete chunk. (with no line breaks) eg.		* a <nowiki><li></nowiki> autocomplete chunk. (with no line breaks) e.g.
	<nowiki> <li style='border-right: solid 50px #30FF30' ></nowiki>		<nowiki> <li style='border-right: solid 50px #30FF30' ></nowiki>

Alan.stiles@open.ac.uk: /* simple_file */

2014-10-08T12:58:03Z

simple_file

← Older revision		Revision as of 12:58, 8 October 2014
Line 48:		Line 48:
	=== simple_file ===		=== simple_file ===

	File needs an additional parameter to be passed to it. This is configured in the workflow. This parameter is the name of a file in the cfg/autocompete directory. This file contains a list of values which are searched (case insensitively) and matches returned. A second parameter of "mode=prefix" can be set to only match values which start with the text being typed, rather than contain it.		File needs an additional parameter to be passed to it. This is configured in the workflow. This parameter is the name of a file in the cfg/autocompete directory. This file contains a list of values which are searched (case insensitively) and matches returned. A second parameter of "mode=prefix" can be set to only match values which start with the text being typed, rather than contain it. Add a second and subsequent parameter by using a semi-colon ( ; ) as delimiter (tested in 3.3.10)

	=== simple_sql ===		=== simple_sql ===

Adb1a11@ecs.soton.ac.uk: Typo fixes

2012-08-13T07:16:04Z

Typo fixes

← Older revision		Revision as of 07:16, 13 August 2012
Line 14:		Line 14:

	There are several kinds of autocomplete scripts:		There are several kinds of autocomplete scripts:
	* ~~thoses~~ that just use the existing data in your repository (these are dead easy as they work out of the box)		* those that just use the existing data in your repository (these are dead easy as they work out of the box).
	* ones which use a file which you place in your ~~repositories~~ cfg/autocomplete/ directory.		* ones which use a file which you place in your repository's cfg/autocomplete/ directory.
	* more clever ones.		* more clever ones.

	You may be able to find new autocomplete scripts and authority files on http://files.eprints.org/		You may be able to find new autocomplete scripts and authority files on http://files.eprints.org/

	Scripts are in (rough) order of complexity to use ~~...~~		Scripts are in (rough) order of complexity to use:

	=== journal_by_name ===		=== journal_by_name ===
Line 36:		Line 36:
	=== name ===		=== name ===

	Attached to a multiple compound name/id field (eg. creators) looks up the name in the existing list in the repository. Can match on any id or given or family. Populates all parts of the current row it can.		Attached to a multiple compound name/id field (e.g. creators) looks up the name in the existing list in the repository. Can match on any id or given or family name. Populates all parts of the current row it can.

	=== title_duplicates ===		=== title_duplicates ===
Line 42:		Line 42:
	This is a slightly odd script as it doesn't actually provide any autocomplete data. What it does is search the list of existing titles to see if there is a match. It only searches if there are 5 or more characters entered so far.		This is a slightly odd script as it doesn't actually provide any autocomplete data. What it does is search the list of existing titles to see if there is a match. It only searches if there are 5 or more characters entered so far.

	If it finds any matches it lists them with a warning that they might be a problem, but does not assist autocompletion. If many matches are made then a short title only is shown, if the list is only 4 or ~~lest~~ then a full citation is shown.		If it finds any matches it lists them with a warning that they might be a problem, but does not assist autocompletion. If many matches are made then a short title only is shown, if the list is only 4 or fewer then a full citation is shown.

	This is set to "on" by default in the hope that it will reduce duplicate submissions.		This is set to "on" by default in the hope that it will reduce duplicate submissions.

Th.lauke@arcor.de: typos corrected

2010-10-22T08:14:45Z

typos corrected

← Older revision		Revision as of 08:14, 22 October 2010
Line 20:		Line 20:
	You may be able to find new autocomplete scripts and authority files on http://files.eprints.org/		You may be able to find new autocomplete scripts and authority files on http://files.eprints.org/

	Scripts are in (rough) order of complexity to use...		Scripts are in (rough) order of complexity to use ...

	=== journal_by_name ===		=== journal_by_name ===
Line 68:		Line 68:
	This is for more complex autocompletion authority files. It works like simple_file except that the file format is more complicated.		This is for more complex autocompletion authority files. It works like simple_file except that the file format is more complicated.

	The file ~~constists~~ of lines which ~~contan~~:		The file consists of lines which contain:
	* a value to search, (eg. "African Journal of Agricultural Research")		* a value to search, (eg. "African Journal of Agricultural Research")
	* a tab		* a tab

Kiz at 09:00, 12 April 2010

2010-04-12T09:00:41Z

← Older revision		Revision as of 09:00, 12 April 2010
Line 1:		Line 1:
	{{reference}}		{{reference}}

	For a how-to, please see [[Autocompletion and Authority Files (Romeo Autocomplete)]]		For a how-to, please see [[Autocompletion and Authority Files (Romeo Autocomplete)]] or [[Adding an Auto-Completer to a non-workflow page]]

	Autocompletion in EPrints 3 consists of serveral stages.		Autocompletion in EPrints 3 consists of serveral stages.

WikiSysop: Reverted edit of AvuPhu, changed back to last version by WikiSysop

2007-08-24T13:29:12Z

Reverted edit of AvuPhu, changed back to last version by WikiSysop

New page

{{reference}}

For a how-to, please see [[Autocompletion and Authority Files (Romeo Autocomplete)]]

Autocompletion in EPrints 3 consists of serveral stages.

* A field in the workflow is configured to say what autocompletion URL to use, plus any additional parameters to pass to the script. This URL must be on the same server (eg. foo.eprints.org) but does not have to be part of the EPrints system.
* The autocomplete script takes the text typed so far (and maybe the additional parameters) and returns a chunk of XML describing possible autocomplete options. This XML consists of a number of rows (how many is up to the script).
* Each row contains some HTML to show the person viewing plus a magic <nowiki><ul></nowiki> block which is hidden from display, but is used by the autocomplete javascript to autocomplete the page.

== Autocomplete Scripts ==

EPrints autocomplete scripts live in /opt/eprints3/cgi/users/lookup/ you can add your own here, or maybe elsewhere if, for example, you needed to use PHP.

There are several kinds of autocomplete scripts:
* thoses that just use the existing data in your repository (these are dead easy as they work out of the box)
* ones which use a file which you place in your repositories cfg/autocomplete/ directory.
* more clever ones.

You may be able to find new autocomplete scripts and authority files on http://files.eprints.org/

Scripts are in (rough) order of complexity to use...

=== journal_by_name ===

Can only be used on the "publication" field. Looks up the publication in the existing publications in the repository and autocompletes the publication. If ISSN and/or publisher exist in the same input component as the journal field they will also be completed if data is available.

=== journal_by_issn ===

As above, but attached to the ISSN field.

=== event_by_name ===

Similar to journal_by_name. Is attached to the event_title field and autocompletes from existing repository data. If they are in the same (multi) input component it will also try and autocomplete event_location, event_dates and event_type.

=== name ===

Attached to a multiple compound name/id field (eg. creators) looks up the name in the existing list in the repository. Can match on any id or given or family. Populates all parts of the current row it can.

=== title_duplicates ===

This is a slightly odd script as it doesn't actually provide any autocomplete data. What it does is search the list of existing titles to see if there is a match. It only searches if there are 5 or more characters entered so far.

If it finds any matches it lists them with a warning that they might be a problem, but does not assist autocompletion. If many matches are made then a short title only is shown, if the list is only 4 or lest then a full citation is shown.

This is set to "on" by default in the hope that it will reduce duplicate submissions.

=== simple_file ===

File needs an additional parameter to be passed to it. This is configured in the workflow. This parameter is the name of a file in the cfg/autocompete directory. This file contains a list of values which are searched (case insensitively) and matches returned. A second parameter of "mode=prefix" can be set to only match values which start with the text being typed, rather than contain it.

=== simple_sql ===

Similar to simple_file but gets its values from a database table.

The table must be in the eprints database used by this repository and start with "ac_". The script needs a param. passed from workflow to indicate the name of the table WITHOUT the ac_ prefix. Eg. if the table was "ac_badgers" the parameter would be "table=badgers". The only field used is "value" which works like the lines in the text file. If you want this to be blindingly fast you can make sure "value" is indexed, and set mode=prefix. With those set autocompleting from a dictionary of half a million words worked cheerfully.

=== romeo ===

(not included in 3.0, expected in 3.1) This script uses the EPrints/Romeo data to provide journal autocomplete data. Should be attached to the publication field. This is almost identical to file, but inserts the required Powered by Sherpa note.

=== url_name_value ===

This works like simple_sql except for the fact it uses three columns. url, name and value. It searches and autocompletes using value, but the human-readable description is supplied by "name" and if url is set then a (more info) link is shown. The link opens a new window to avoid mid-form trauma.

=== file ===

This is for more complex autocompletion authority files. It works like simple_file except that the file format is more complicated.

The file constists of lines which contan:
* a value to search, (eg. "African Journal of Agricultural Research")
* a tab
* a <nowiki><li></nowiki> autocomplete chunk. (with no line breaks) eg.
<nowiki> <li style='border-right: solid 50px #30FF30' ></nowiki>

=== external source ===

This takes all the ideas above, and extends them to make an API call to an external data source. This has the advantage that you are always referring to the authoritative source, but the disadvantage that you are reliant on both the network being up and the external source being available.

It breaks down into two parts:
* the autocompleter call in the web page
* the script being called

For an example, here is one way to query the RoMEO data directly:

First, set the autocompleter in the eprints workflow:
<pre>
<component type="Field::Multi">
<title>Article Publication Details</title>
<field ref="publication" input_lookup_url="{$config{perl_url}}/get_journals" />
<field ref="publisher" />
<field ref="issn" />
</component>
</pre>

Next have the script:
<pre>
use strict;
use HTTP::Request;
use LWP::UserAgent;
use XML::Twig;

use Data::Dumper;
use EPrints;

my $journal_data = {};

sub urldecode{
my ($url) = @_;
$url =~ s/%([0-9a-f][0-9a-f])/pack("C",hex($1))/egi;
$url =~ s/\x2B/ /; # swap '+' for ' '
return $url;
}

# XML::Twig's routine for dealing with a journal entry
sub process_journal {
my ( $twig, $journal ) = @_;

# get the components
my $title = urldecode( $journal->first_child('jtitle')->text );

my $zetoc = urldecode( $journal->first_child('zetocpub')->text )
if $journal->first_child('zetocpub');
my $romeo = urldecode( $journal->first_child('romeopub')->text )
if $journal->first_child('romeopub');
my $issn = urldecode( $journal->first_child('issn')->text )
if $journal->first_child('issn');

my $publisher = $romeo;
$publisher = $zetoc if (not $publisher && $zetoc);

# build a lub of html based on the components
my $html .= "<li>$title";
$html .= "<br />published by $publisher" if $publisher;

$html .= "<ul>";
if ($title) {
$html .= "<li id='for:value:component:_publication'>$title</li>";
}
if ($publisher) {
$html .= "<li id='for:value:component:_publisher'>$publisher</li>";
}
if ($issn) {
$html .= "<li id='for:value:component:_issn'>$issn</li>";
}
$html .= "</ul></li>\n";
warn "\n\n$html\n\n";
# save the html
$journal_data->{$title} = $html;

1;
} ## end process_journal

# get a list of journals that match the query
sub get_journals {
my $journal = shift;
my @html = ();

if ($journal) {
return ("<ul><li>keep typing....</li></ul>") if (length($journal) < 3);

$journal =~ s/\s+/\+/;
my $query = "http://www.sherpa.ac.uk/romeoapi.php?qtype=starts&jtitle=$journal";

my $request = HTTP::Request->new( GET => "$query" );

my $ua = LWP::UserAgent->new();
my $response = $ua->request($request);
my $content = $response->content();

my $twig = XML::Twig->new(
'keep_encoding' => 1,
'TwigRoots' => { 'journals' => 1 },
'TwigHandlers' => { 'journal' => \&process_journal, }
);
$twig->parse($content);
if (scalar keys %{$journal_data}) {
push @html, "<ul class='journals'>\n";
foreach my $title (sort keys %{$journal_data}) {
push @html, "$journal_data->{$title}\n";
} ## end of foreach my $title (sort keys %{$journal_data})
push @html, "</ul>\n";
} ## end of if (scalar keys %{$journal_data}) ...
} else {
push @html, "\n";
}

return (join "\n", @html)

} ## end get_journals

my $session = EPrints::Session->new();

# we need the send an initial content-type
print <<END;
<?xml version="1.0" encoding="UTF-8" ?>

END

# then we send the fragment of html for the autocompleter
print get_journals( lc $session->param( "q" ) );

$session->terminate;
</pre>

WikiSysop: Reverted edit of AvuPhu, changed back to last version by Kiz

2007-08-22T11:45:28Z

Reverted edit of AvuPhu, changed back to last version by Kiz

New page

Kiz: Add in an example for an external data source

2007-08-13T15:20:16Z

Add in an example for an external data source

New page

WikiSysop: Reverted edit of QomIba, changed back to last version by Sp

2007-04-11T15:53:33Z

Reverted edit of QomIba, changed back to last version by Sp

New page

{{reference}}

For a how-to, please see [[Autocompletion and Authority Files (Romeo Autocomplete)]]

Autocompletion in EPrints 3 consists of serveral stages.

* A field in the workflow is configured to say what autocompletion URL to use, plus any additional parameters to pass to the script. This URL must be on the same server (eg. foo.eprints.org) but does not have to be part of the EPrints system.
* The autocomplete script takes the text typed so far (and maybe the additional parameters) and returns a chunk of XML describing possible autocomplete options. This XML consists of a number of rows (how many is up to the script).
* Each row contains some HTML to show the person viewing plus a magic <nowiki><ul></nowiki> block which is hidden from display, but is used by the autocomplete javascript to autocomplete the page.

== Autocomplete Scripts ==

EPrints autocomplete scripts live in /opt/eprints3/cgi/users/lookup/ you can add your own here, or maybe elsewhere if, for example, you needed to use PHP.

There are several kinds of autocomplete scripts:
* thoses that just use the existing data in your repository (these are dead easy as they work out of the box)
* ones which use a file which you place in your repositories cfg/autocomplete/ directory.
* more clever ones.

You may be able to find new autocomplete scripts and authority files on http://files.eprints.org/

Scripts are in (rough) order of complexity to use...

=== journal_by_name ===

Can only be used on the "publication" field. Looks up the publication in the existing publications in the repository and autocompletes the publication. If ISSN and/or publisher exist in the same input component as the journal field they will also be completed if data is available.

=== journal_by_issn ===

As above, but attached to the ISSN field.

=== event_by_name ===

Similar to journal_by_name. Is attached to the event_title field and autocompletes from existing repository data. If they are in the same (multi) input component it will also try and autocomplete event_location, event_dates and event_type.

=== name ===

Attached to a multiple compound name/id field (eg. creators) looks up the name in the existing list in the repository. Can match on any id or given or family. Populates all parts of the current row it can.

=== title_duplicates ===

This is a slightly odd script as it doesn't actually provide any autocomplete data. What it does is search the list of existing titles to see if there is a match. It only searches if there are 5 or more characters entered so far.

If it finds any matches it lists them with a warning that they might be a problem, but does not assist autocompletion. If many matches are made then a short title only is shown, if the list is only 4 or lest then a full citation is shown.

This is set to "on" by default in the hope that it will reduce duplicate submissions.

=== simple_file ===

File needs an additional parameter to be passed to it. This is configured in the workflow. This parameter is the name of a file in the cfg/autocompete directory. This file contains a list of values which are searched (case insensitively) and matches returned. A second parameter of "mode=prefix" can be set to only match values which start with the text being typed, rather than contain it.

=== simple_sql ===

Similar to simple_file but gets its values from a database table.

The table must be in the eprints database used by this repository and start with "ac_". The script needs a param. passed from workflow to indicate the name of the table WITHOUT the ac_ prefix. Eg. if the table was "ac_badgers" the parameter would be "table=badgers". The only field used is "value" which works like the lines in the text file. If you want this to be blindingly fast you can make sure "value" is indexed, and set mode=prefix. With those set autocompleting from a dictionary of half a million words worked cheerfully.

=== romeo ===

(not included in 3.0, expected in 3.1) This script uses the EPrints/Romeo data to provide journal autocomplete data. Should be attached to the publication field. This is almost identical to file, but inserts the required Powered by Sherpa note.

=== url_name_value ===

This works like simple_sql except for the fact it uses three columns. url, name and value. It searches and autocompletes using value, but the human-readable description is supplied by "name" and if url is set then a (more info) link is shown. The link opens a new window to avoid mid-form trauma.

=== file ===

This is for more complex autocompletion authority files. It works like simple_file except that the file format is more complicated.

The file constists of lines which contan:
* a value to search, (eg. "African Journal of Agricultural Research")
* a tab
* a <nowiki><li></nowiki> autocomplete chunk. (with no line breaks) eg.
<nowiki> <li style='border-right: solid 50px #30FF30' >"African Journal of Agricultural
Research" published by "Academic Publishers"<br /><small>(a Green
publisher)</small>ISSN: 1991-637X<ul><li id="for:value:component:_publication">African
Journal of Agricultural Research</li><li id="for:value:component:_publisher">Academic
Publishers</li><li id="for:value:component:_issn">1991-637X</li></ul></li></nowiki>

See below for more information on the meaning of this arcane chunk!

=== sql ===

As for simple_sql except that a second column named "xml" is used to provide the actual results returned (value is still searched).

The xml column contains data in the autocomplete <nowiki><li></nowiki> format described below.

= Making a custom script =

Autocompletion scripts are configured to eprint fields within the workflow. If the field is multiple then the same script is attached to each input row.

The only parameter you need to look at is "q" which contains the text being autocompleted. For simple fields (eg. text), that is ones which only have one input-box per value. Not names, compound or pagerange etc.. the response should be of the format:
<nowiki>
<?xml version="1.0" encoding="UTF-8" ?>
<ul>
<li class="ep_first">Human Friendly Text <ul><li id='for:value:relative:'>text-to-insert</li></ul><li>
<li>Human Friendly Text <ul><li id='for:value:relative:'>text-to-insert</li></ul><li>
<li>Human Friendly Text <ul><li id='for:value:relative:'>text-to-insert</li></ul><li>
<li>Human Friendly Text <ul><li id='for:value:relative:'>text-to-insert</li></ul><li>
etc.
</ul></nowiki>

The ep_first isn't really needed, but it makes the rendering look a little nicer.

== Other useful CGI parameters ==

All parts of the field (or field row in multiple fields) get sent as CGI parameters. The name of these parameters is the ID of the HTML input element itself, but with the relative prefix removed (phew!).

Simple example: title field. One single value. It's not relevant, just use "q".

More complex example: pagerange field. While you were typing in the "to" box (the second one). It would send "?q=45&_from=12&_to=45". Obviously the numbers are made up. q= will always be the same as one of the values.

Even more complex example: creators field. Which is a multiple compound field. Parts sent would be q, _id, _name_given and _name_family.

For an explanation of how the id's are generated, and what a relative prefix is, see [[Understanding IDs in Workflow Forms]].

== The autocompletion instructions ==

The instructions for ''what'' to autocomplete if the row is selected is contained in the <ul> list inside the <li>.

Each item in the list is a single instruction.

Each item in the list has an id attribute containing instructions on what to autocomplete. (yes that means repeated id values which is bad XML and we'll fix it in a later version...)

The value inside the item describes what to insert, the id describes where and how.

The id looks like this:

"for:" + ("block" or "value") + ":" + ("relative" or "component" or "absolute") + ":" + freetext

Examples:

id="for:value:relative:"
id="for:value:relative:_name_family"
id="for:value:component:_issn"
id="for:block:absolute:my_special_id"

"value" means insert the value into an <input> element (with the indicated id).

"block" means replace the block with the indicated id.

"component" means that the freetext is the ID to modify, but missing the component prefix. For example "_issn" gives "id7_issn" (assuming id7 is the current component)

"relative" means the freetext is the ID to modify but missing the row prefix. For example in a multiple text field (foo) using "" for the free text would give an id of something like "id3_foo_4". For a single date field (birthday) a freetext of "_year" would give an id looking something like "id2_birthday_year".

"absolute" means that the freetext is the ID to modify. Absolute is a bit risky, as you can't rely on getting the same component prefix every time. It does, however, give you the chance to do Cool Stuff<sup>TM</sup>. For example add a XHTML input compontent just containing: <tt><nowiki><div id="special_comments"></div></nowiki></tt> and then make part of the autocomplete <tt><nowiki><li id="for:block:absolute:special_comments"><p>Hi Mom!</p></li></nowiki></tt> (but something more relevant, obviously)

=== How are these ID's generated anyway? ===

See [[Understanding IDs in Workflow Forms]].

=== What happens if the ID doesn't exist? ===

Nothing, the autocompleter does not raise an error. It just autocompletes all the things it can. This is handy if the workflow changes slightly, but makes debugging a bit trickier.

=== Some examples ===

Please note these examples have line breaks in which is illegal in the "file" script files (but not in SQL or in custom scripts).

<nowiki><li style='border-right: solid 50px #30FF30'>
"African Journal of Biotechnology" published by "Academic Publishers"<br />
<small>(a Green publisher)</small>ISSN: 1684-5315
<ul>
<li id="for:value:component:_publication">African Journal of Biotechnology</li>
<li id="for:value:component:_publisher">Academic Publishers</li>
<li id="for:value:component:_issn">1684-5315</li>
</ul>
</li></nowiki>

The above example autocompletes the issn, publication and publisher (text) fields in the current component.

<nowiki><li>
B. Draut
<small>(author of 3 items in this repository)</small>
<ul>
<li id="for:value:relative:_name_family">Draut</li>
<li id="for:value:relative:_name_given">B.</li>
<li id="for:value:relative:_name_honourific"/>
<li id="for:value:relative:_name_lineage"/>
<li id="for:value:relative:_id">434533X</li>
</ul>
</li></nowiki>

This completes relative to the current row of a compound field the compound is a name field (called name) and a text field (called id). This is the config. for the creators and editors fields by default. Note that it tries to autocomplete the honourific field even though it doesn't exist and it's got no value to autocomplete. This means that if it happens to exist, this autocompletion will remove any text from the field.

= Don't Forget to Share! =

If you write a really useful autocomplete script, or a useful data file for "file" or "simple_file", why not upload it to http://files.eprints.org/ so lots more people can benefit!

Sp: /* The autocompletion instructions */ typo

2007-02-13T23:53:07Z

The autocompletion instructions: typo

← Older revision		Revision as of 23:53, 13 February 2007
Line 117:		Line 117:
	== The autocompletion instructions ==		== The autocompletion instructions ==

	The instructions for ''what'' to autocomplete if the row is selected is contained in the <ul&~~gtl~~ list inside the <li>.		The instructions for ''what'' to autocomplete if the row is selected is contained in the <ul> list inside the <li>.

	Each item in the list is a single instruction.		Each item in the list is a single instruction.