Class MultiDynaMetapushTable
Object
|
+--Table
|
+--VisualTable
|
+--DynaMetapushTable
|
+--MultiDynaMetapushTable
- class
MultiDynaMetapushTable
- extends DynaMetapushTable
A data table that can be fed with real-time data
delivered by Lightstreamer Server and displayed into a screen table
according to ADD, UPDATE and DELETE commands received as pushed values,
which instruct the data table to either add a row, just modify values on a row
or delete a row.
However, the values for each data table row are provided:
- in part through the ADD and UPDATE commands;
- in part through a second-level, or "underlying" item, determined by
the row key, which defines an implicit row-like data table, automatically
created and managed according to the row lifecycle.
In synthesis, each time a new row is created, an underlying data table is also created
and subscribed automatically to feed fields not handled by the first-level
updates. This table is a mono-item table, where the item name that is used
is the key value associated to the row. The item is subscribed to in
"MERGE" mode, with snapshot request and with the same maximum frequency
setting as for the first-level items (including the "unfiltered" case).
All other subscription properties are left as the default.
When the row is deleted, the underlying data table is also removed.
We call this a "MultiMetapush logic" behaviour, which is hence
a two-level extension of the "COMMAND logic" behavior.
The class contains the subscription details and the event handlers
needed to allow Lightstreamer to manage both first-level and second-level
items and to display the real-time data.
A screen table suitable for the visualization of pushed values is
dynamically maintained by Lightstreamer, starting from an HTML hidden
template row, containing cells. The template row can be provided as any
HTML element owning the "source='Lightstreamer'" special attribute,
while the element "ID" attribute defines the screen table id.
The association is made when the data table is brought to the "running"
state, through the identifier supplied to PushPage.addTable(),
that must match the screen table id.
The contained cells are defined as any DOM elements owning the
"source='Lightstreamer'" special attribute, together with a "field"
attribute.
For each pushed update, the involved row is determined and each
value is displayed in a cell that is associated to the involved row
and field. If necessary, new rows are cloned from the hidden template
and attached after it, or existing rows are dropped.
By default the new/updated value will be set as the cell's content
(or its value in case the cell is an INPUT or a TEXTAREA element). It is possible
to override this behavior by specifying a special "update" attribute containing the
name of the attribute of the cell to be updated. Any string can be specified;
moreover a value of a stylesheet can be specified using the "style.attribute"
form (note that the DOM attribute name should be used, not the CSS name; e.g.
"style.backgroundColor" is correct, while "style.background-color" is not).
WARNING: also events like "onclick" can be assigned; in such cases make sure that no
malicious code will be pushed by the Data Adapter (for example through
the injection of undesired JavaScript code).
NOTE: the cell/field association depends on the value specified in the "field"
attribute of each cell, which should be a valid field descriptor.
Only one cell for each field is supported in the template.
Note that the template element can contain an arbitrary HTML structure
and should contain HTML cells to be used to display the row field
values. However, it should not contain elements to which an ID has been
assigned, because the elements will be cloned and the HTML
specification prescribes that an ID must be unique in the document.
(The ID of the template element, required by Lightstreamer, is not
cloned).
More visualization actions can be performed through the provided event
handlers.
See:Defined in lspushpage.js
Method Summary |
SchemaDescriptor
|
getUnderlyingSchema()
Inquiry method that returns the SchemaDescriptor associated to the second-level data tables.
|
void
|
setUnderDataAdapter(<String> dataAdapter)
Setter method that sets the name of the underlying Data Adapter
(within the Adapter Set used by the current session)
that supplies all the second-level items.
|
Methods inherited from class DynaMetapushTable |
setMetapushFields, onChangingValues, setAutoScroll, setMetapushSort, getMetapushSortField, getMetapushSortFieldName, isDescendingSort, isNumericSort, isCommaAsDecimalSeparator, setMaxDynaRows, getMaxDynaRows, onCurrentPagesChanged, goToPage, getDisplayedPage, getCurrentPages
|
Methods inherited from class Table |
getSchema, getGroup, setDataAdapter, getId, setSelector, setItemsRange, setRequestedMaxFrequency, setRequestedBufferSize, setSnapshotRequired, onItemUpdate, onLostUpdates, onEndOfSnapshot, onStart, getClassName
|
MultiDynaMetapushTable
MultiDynaMetapushTable(<GroupDescriptor> tGroup, <SchemaDescriptor> tSchema, <String> tSubscriptionMode, <SchemaDescriptor> tUnderSchema)
Creates an object to be used to describe a data table to be managed
with a "MultiMetapush logic" behaviour. The table rows are displayed into
dynamically generated HTML rows.
The object can be supplied to PushPage.addTable() and
PushPage.removeTable(), in order to bring the data table to
"running" or back to "inactive" state.
Parameters:
tGroup
- A group descriptor object, which identifies the first-level items that provide the data table rows. Usually, the group consists of just one item, whose updates are commands that specify whether to ADD, UPDATE or DELETE data table rows. If the group consists of more than one item, then the updates for the different items are simply mixed and concur to the maintenance of the same data table. However, if the same key is used by different items, it refers to distinct rows on the data table, which will be related to identical underlying tables.
An Array of item names or a String group identifier can also be used directly, instead of a group descriptor object.
Note that, in case a GroupListDescriptor or an array is used, a LiteralBasedProvider or equivalent Metadata Adapter is needed on the Server in order to understand the subscription request.
tSchema
- A schema descriptor object, which identifies the fields provided by the first-level items. An Array of field names or a String schema identifier can also be used directly, instead of a schema descriptor object.
In case a SchemaListDescriptor or a field name array is specified, field names can be used in the cells as field descriptors; otherwise, only field positions can be used.
A null value is also allowed. In this case, the names for the fields should be supplied by the associated screen tables; hence, field names should be used in the cells as field descriptors. Names starting with a "#" character will be treated as extra fields and not included in the schema (hence, if extra fields have to be put in the cells, in order to use this feature, names starting with "#" should be chosen for the extra fields). Names preceded by the "$" character, on the other hand, identify fields provided by the second-level items and are not included in the first-level schema. If COMMAND subscription mode is specified, then the special "key" and "command" fields are automatically added.
Note that, in case a SchemaListDescriptor, an array or a null value is supplied, a LiteralBasedProvider or equivalent Metadata Adapter is needed on the Server in order to understand the subscription request.
tSubscriptionMode
- the subscription mode for the first-level items of the main table, required by Lightstreamer Server. This kind of data table is suited for COMMAND mode.
tUnderSchema
- a schema descriptor object, which identifies the fields provided by the second-level items (i.e. the fields that represent the underlying data table columns). An Array of field names or a String schema identifier can also be used directly, instead of a schema descriptor object.
In case a SchemaListDescriptor or a field name array is specified, field names can be used in the cells as field descriptors, provided that the names are preceded by the "$" character; a real field name can also be used whenever there is no conflict with first-level fields. Otherwise, only field positions can be used; in this case, the field position indexes to be used should start from the highest position of the first-level schema + 1.
Similar considerations hold for the DynaMetapushTable.setMetapushSort(), DynaMetapushTable.getMetapushSortField() and DynaMetapushTable.getMetapushSortFieldName() methods, when second-level fields are used for sorting; in particular, the latter method returns the real field name whenever there is no conflict with first-level fields and returns the name preceded by the "$" character otherwise.
A null value is also allowed. In this case, the names for the fields should be supplied by the associated screen tables; hence, the field names should be used in the cells as field descriptors, again provided that the names are preceded by the "$" character.
Note that, in case a SchemaListDescriptor, an array or a null value is supplied, a LiteralBasedProvider or equivalent Metadata Adapter is needed on the Server in order to understand the subscription request.
Note that the first-level and second-level schemas must be declared in the same way, i.e. both through a SchemaListDescriptor (or an array, or null) or both through a SchemaIdDescriptor (or an identifier).
getUnderlyingSchema
SchemaDescriptor getUnderlyingSchema()
Inquiry method that returns the SchemaDescriptor associated to the second-level data tables.
If the table was created with a SchemaListDescriptor or an array of strings associated with the second-level tables, then a SchemaListDescriptor is returned.
If the table was created with a SchemaIdDescriptor or a string associated with the second-level tables, then a SchemaIdDescriptor is returned.
If the table was created with a null as SchemaDescriptor associated with the second-level tables, and is
in "running" state, then a SchemaListDescriptor is returned, otherwise null is returned.
Returns:
The SchemaDescriptor associated to the data table.
setUnderDataAdapter
void setUnderDataAdapter(<String> dataAdapter)
Setter method that sets the name of the underlying Data Adapter
(within the Adapter Set used by the current session)
that supplies all the second-level items. All the possible second-level
items should be supplied in "MERGE" mode with snapshot available.
The Data Adapter name is configured on the server side through
the "name" attribute of the <data_provider> element, in the
"adapters.xml" file that defines the Adapter Set (a missing attribute
configures the "DEFAULT" name).
Default value: "DEFAULT".
Lifecycle: The underlying Data Adapter name should be set and changed while
the main data table is in "inactive" state. Each time a new underlying data table is
created and brought to "running" state due to an ADD operation on the main data table,
the underlying Data Adapter name is specified in the subscription request.
Parameters:
dataAdapter
- the name of the Data Adapter. A null value is equivalent to the "DEFAULT" name.
Lightstreamer HTML Client API
Documentation generated by
JSDoc on Tue May 22 11:46:54 2012