NewFromRecord (XmlDoc function): Difference between revisions

Latest revision as of 22:04, 20 August 2019

Create a new XmlDoc from the current record (XmlDoc class)

[Requires Janus SOAP]

This shared function creates a new XmlDoc object that contains the fields and fieldgroups from the current record. Among other things, the result XmlDoc can be used to copy a record, using the AddToRecord subroutine.

The field and fieldgroup extraction performed by NewFromRecord is the same operation that is performed by the LoadFromRecord subroutine and by the ToXmlDoc function in the Record class, as is further described below in "Usage notes".

Syntax

%doc = [%(XmlDoc):]NewFromRecord[( [AttributeValues= boolean], - [AttributeNames= boolean], - [NamesToLower= boolean], - [AllowUnreversible= boolean], - [CodepageTable= boolean], - [Base64Encode= boolean], - [CharacterMap= characterToUnicodeMap], - [Allownull= boolean], - [Recordnumber= number], [File= string])] Throws CharacterTranslationException

Syntax terms

%doc	`NewFromRecord` returns a new `XmlDoc` object.
`[%(XmlDoc):]`	The optional class name in parentheses denotes a virtual constructor method. See "Usage notes", below, for more information about invoking an `XmlDoc` virtual constructor.
`AttributeValues`	This name required argument is a `Boolean` value that indicates whether a field value will be stored as "XML text" or as an XML attribute (belonging to its field, which is an `XmlDoc` element). For example, `<APSUBUND>COMM</APSUBUND>` is text format, and `<APSUBUND value="COMM"/>` is attribute value format. The default value is `False`, which produces text format. In this format, the value of a field will be converted to base64 in the `XmlDoc` if the field contains a byte that is: Equal to X'00', if the `AllowNull` property of the `XmlDoc` is `False`. Between X'00' and X'3F'. Not translatable from EBCDIC to Unicode, using either the standard Unicode translation table or the base codepage translation table, as determined by the `CodepageTable` argument of `NewFromRecord`. Not invertible when translating from EBCDIC to Unicode and back to EBCDIC using the standard Unicode translation table, if the `CodepageTable` argument is `False`. This argument must be `False` if the `XmlDoc` is to be used as the method object of the `AddToRecord` subroutine.
`AttributeNames`	This name required argument is a `Boolean` value that indicates whether each field name is to be stored in the `XmlDoc` as an element name or as the value of a "name" attribute. For example, `<APSUBUND>COMM</APSUBUND>` is element-name format, and the following is name-as-attribute format: <field name="APSUBUND"> COMM </field> The default value as of `Sirius Mods` version 7.6 (and maintenance back to version 7.3) is `True`, which produces name-as-attribute format. Formerly, the default value was `False`. The name-as-attribute format from the `True` option is better suited to operations on the `XmlDoc`, particularly a record copying operation. The element-name format from the `False` option produces more compact output when the `XmlDoc` is serialized. This argument must be `True` if the `XmlDoc` is to be used as the method object of the `AddToRecord` subroutine.
`NamesToLower`	This name required argument is a `Boolean` value that indicates whether field names are stored in all lowercase characters. The default value is `False`, which does not translate uppercase name characters to lowercase. If the `XmlDoc` is to be used for record copying, this argument should probably be `False`.
`AllowUnreversible`	This name required argument is a `Boolean` value that indicates whether a request is cancelled if a field name would be changed irreversibly by lowercasing or by replacing with a period the characters that would be invalid in an XML document. The default value is `False`, which allows request cancellation to alert you about unreversible field names. If the `XmlDoc` is to be used for record copying, this argument should probably be `False`.
`CodepageTable`	This name required argument is a `Boolean` value; if `True`, the translations defined by the base Unicode codepage are used when translating from EBCDIC to Unicode for storing in the `XmlDoc`. This argument is for the unusual case where you anticipate that the XML document is to be used later by `AddToRecord`, and the standard Unicode translation tables in place when `AddToRecord` is invoked may differ from those in place when the record was copied to the `XmlDoc`. The default value is `False`, which uses the standard Unicode translation tables, including any modifications specified in `UNICODE Trans` or `UNICODE Map` commands. The advantage of using `CodepageTable=False` is that it will allow you to readily modify the `XmlDoc` directly (that is, with the `AddElement` and `AddAttribute` methods). Those operations will use the standard Unicode translation tables; there is no way to perform them using the base codepage translation tables.
`Base64Encode`	This name required argument is a `Boolean` value. The default is `True`, which indicates that before storing a field's value in the `XmlDoc`, the value is base64 encoded if needed. See this ToXmlDoc usage note which describes the conditions that would require base64 encoding. If `Base64Encode` value is `False`, field values are not base64 encoded. This means: Control and uninvertible characters are translated to their Unicode counterparts. X'00' (if the `AllowNull` argument is not `True`) and untranslatable characters can cause request cancellation, unless they are mapped by the `CharacterMap` argument. (An unmapped untranslatable character actually throws a `CharacterTranslationException` exception, which results in cancellation if not caught.) `Base64Encode` is available as of `Model 204` version 7.5.
`CharacterMap`	This name required argument is a `CharacterToUnicodeMap` value. If a non-null value is provided, then the specified map is used to translate non-`UTF8`/`16` field values from EBCDIC to Unicode before storing in the `XmlDoc`. Also, if a non-null value is provided, then the `Base64Encode` argument is forced to the value `True`, and the processing indicated by that is performed. `CharacterMap` is available as of `Model 204` version 7.5.
`AllowNull`	The value of this name required `Boolean` argument, which defaults to `False`, is copied to the `AllowNull` property of the `XmlDoc` created by `NewFromRecord`. The `XmlDoc`'s `AllowNull` property, in turn, determines whether field values that contain the X'00' character are stored in the `XmlDoc` with base64 encoding. Such values are base64 encoded if the `AllowNull` property is `False` (the default). For an example, see "Handling records with null characters", below.

Usage notes

NewFromRecord is a virtual constructor and as such can be called with no method object, with an explicit class name, or with an object variable, even if that object is Null:
%doc = NewFromRecord %doc = %(XmlDoc):NewFromRecord %doc = %doc:NewFromRecord
Whether to use ToXmlDoc, LoadFromRecord, or NewFromRecord depends on what is most convenient for your application. If you are already using a Record object that references the desired record, using ToXmlDoc may be more convenient; if not, then either NewFromRecord or LoadFromRecord (both of which require that the method be contained in a record loop, for example, For Each Record) may be more convenient. You must use LoadFromRecord if you want to add the record's content as a subtree to a non-empty XmlDoc; in other cases the NewFromRecord virtual constructor may be your choice.
Since NewFromRecord and ToXmlDoc create new XmlDoc objects, they have the AllowNull argument for setting the created XmlDoc's AllowNull poperty; LoadFromRecord does not have the AllowNull argument.

As stated, both NewFromRecord and LoadFromRecord must be contained in a record loop, for example, an FRN block, and they may not be invoked within a fieldgroup context.

Except for these considerations, ToXmlDoc, NewFromRecord, and LoadFromRecord all perform the same operation and have the same arguments, so.
See the additional comments in the ToXmlDoc Usage notes, which apply equally to NewFromRecord and LoadFromRecord. The topics discussed there are:
- Invalid characters in field names
- Using AllowUnreversible for lowercase or invalid field name characters
- Base64 encoding of field values
- Field level security
- LOB fields
- Record locks

Examples

In addition to the examples in the following section, see the following examples in the ToXmlDoc article, both of which apply equally to LoadFromRecord and NewFromRecord:

The "AttributeValues, AttributeNames, and NamesToLower arguments" example
The "Getting record lock" example

Handling records with null characters

In the following example, NewFromRecord adds record content that includes a null character to an XmlDoc. The default False value of the AllowNull parameter is passed to the XmlDoc and causes the null character to be base64 encoded. This conforms to the XML Recommendation, which does not allow null characters in an XML document.

The following fragment:

%s = 'Field with null/' With '00':X With '/' Store Record FOO = %s End Store %r = $CurRec FRN %r %doc = %doc:NewFromRecord End For PrintText {~} = {%doc:AllowNull} %doc:Print

produces this output:

%doc:AllowNull = False <Record version="1" file="QAWORK" number="1"> <field name="FOO" encoding="base64"> xomFk4RApomjiECVpJOTYQBh </field> </Record>

In the above output, notice that FOO is base64 encoded, because it contains a null character, and null characters are not allowed in an XmlDoc whose AllowNull property is False. The following fragment:

%s = 'Field with null/' With '00':X With '/' Store Record FOO = %s End Store %r = $CurRec FRN %r %doc = %doc:NewFromRecord(AllowNull=True) End For PrintText {~} = {%doc:AllowNull} %doc:Print

produces the following output:

%doc:AllowNull = True <Record version="1" file="QAWORK" number="1"> <field name="FOO"> Field with null// </field> </Record>

In the above output, FOO is not base64 encoded; the XmlDoc contains a null character, which is displayed by the Print method using a character reference (). This may be useful for visually inspecting the contents of the XmlDoc, again noting that such a document is not, strictly speaking, conformant to the XML Recommendation.

The description above of the AttributeValues argument lists all conditions which force base64 encoding of the "field" element.

XmlDoc class XmlNode class XmlNodelist class	List of XmlDoc methods List of XmlNode methods List of XmlNodelist methods List of XmlDoc API methods	XmlDoc methods syntax XmlNode methods syntax XmlNodelist methods syntax
Notation conventions for methods