Functions - Revision history

Af05v@ecs.soton.ac.uk at 12:57, 14 October 2015

2015-10-14T12:57:08Z

Pm705 at 15:01, 8 February 2010

2010-02-08T15:01:41Z

Moj at 12:21, 3 January 2007

2007-01-03T12:21:47Z

WikiSysop at 10:25, 6 March 2006

2006-03-06T10:25:55Z

WikiSysop at 17:49, 1 March 2006

2006-03-01T17:49:22Z

WikiSysop at 17:48, 1 March 2006

2006-03-01T17:48:21Z

New page

==Multi Page Metadata Input (v2.3.0)==
If you want to split the metadata input into more than one page, you can, by adding <page name="foo" /> elements in between <field> elements in metadata-types.xml.

The "name" attribute is used so that EPrints knows which page it's currently on. It can also be used to define a custom title for a page of fields, and to specify validation requirements for that page.

===Metafield input page name===
Eg. The title of a metadata input page is taken from the phrase "metapage_title_''pagename''". It may have any of the following pins:

; type : The type of the current submission. Article, Book, or whatever.
; eprintid : The ID number of the current submission.
; desc : The short description of the item. Usually the title.

===Per-page Validation===
The simple validation will be checked for each field on the sub page. This means that an invalid URL will raise a problem and not let the submitter continue. However if you have a more complex validation issue, such as an exclusion or a co-dependancy, you will need to edit the '''ArchiveValidateConfig.pm''' config file, and edit this subroutine:

<code>
sub validate_eprint_meta_page
{
my( $eprint, $session, $page, $for_archive ) = @_;

my @problems = ();

return @problems
}
</code>
The options are as for validate_eprint_meta except that $page is the sub-page to validate. @problems should be an array of XHTML objects describing any problems with the data submitted for that page.

==Submission Customisation XX==
==Filters XX==
==Searches XX==
==OAI XX==
==Latest Tool XX==
==Metadata Field Render Options (v2.3.0)==
Render options are settings for a metadata field which control how it is rendered (but nothing else). Some render options are only meaningful for certain types.

===Setting in Metadata Fields Configuration===
Render options can be specified as properties of a metadata field in ArchiveMetadataFieldsConfig.pm in which case they apply to that field (unless over ridden). In this case they are a hash reference, for example:

<code>
{ name => "creators", type => "name", render_opts=>{ order=>"gf" } },
</code>
This sets the "order" render option of the creators field to be "gf".

===Setting in views and citations===
Render options can also be specified in views and citations. If you don't want them to apply except in the given view or citation. For example, in citations:

<code>
@title;magicstop@
</code>
Magicstop is a boolean option so this is the same as saying:

<code>
@title;magicstop=1@
</code>
In views you can use

<code>
"some_date_field;res=year"
</code>
To make a view that browses by the values of a date field as if it were a "year" field.

===Available options===
Boolean options with no value default to true (1).

; magicstop : Boolean. Applies to text and longtext fields. If true then render the value with a full stop on the end unless the value already ends with "." "!" or "?". Handy for getting citations right.
; noreturn : Boolean. Applies to text and longtext fields. Turns all Carriage Return and Line Feed characters into whitespace. Handy when you have authors entering titles with linebreaks in which should only be displayed under some circumstances.
; order : "gf" or "fg". Applies to name fields. Override how this name field will be rendered. Either "given-name family-name" or "family-name, given-name".
; quiet : Boolean. If true then and the value is not set, don't print the ugly "UNSPECIFIED" just print an empty string.
; res : "day", "month" or "year". Default is "day". Applies to date fields only. Resolution at which to deal with the dates. @foo;res=year@ will always render just the year part of the "foo" field.

← Older revision		Revision as of 12:57, 14 October 2015
Line 1:		Line 1:
−	~~{{development}}~~
	{{manual}}		{{manual}}
	[[Category:Configuration]]		[[Category:Configuration]]

@@ Line 1: / Line 1: @@
 {{development}}
 {{manual}}
 ==Multi Page Metadata Input (v2.3.0+)==
 If you want to split the metadata input into more than one page, you can, by adding <page name="foo" /> elements in between <field> elements in metadata-types.xml.

← Older revision		Revision as of 12:21, 3 January 2007
Line 1:		Line 1:
		+	{{development}}
	{{manual}}		{{manual}}
	==Multi Page Metadata Input (v2.3.0+)==		==Multi Page Metadata Input (v2.3.0+)==

← Older revision		Revision as of 17:49, 1 March 2006
Line 1:		Line 1:
		+	{{manual}}
	==Multi Page Metadata Input (v2.3.0)==		==Multi Page Metadata Input (v2.3.0)==
	If you want to split the metadata input into more than one page, you can, by adding <page name="foo" /> elements in between <field> elements in metadata-types.xml.		If you want to split the metadata input into more than one page, you can, by adding <page name="foo" /> elements in between <field> elements in metadata-types.xml.

@@ Line 1: / Line 1: @@
 {{manual}}
-==Multi Page Metadata Input (v2.3.0)==
+==Multi Page Metadata Input (v2.3.0+)==
 If you want to split the metadata input into more than one page, you can, by adding <page name="foo" /> elements in between <field> elements in metadata-types.xml.
@@ Line 20: / Line 20: @@
+  {
          my( $eprint, $session, $page, $for_archive ) = @_;
-−
          my @problems = ();
-−
          return @problems
+  }