Class VisualTable
Object
|
+--Table
|
+--VisualTable
-
Direct Known Subclasses:
-
ChartTable, DynaMetapushTable, ScrollTable, OverwriteTable, DynaScrollTable, MetapushTable
- class
VisualTable
- extends Table
The base class for all the data-table classes that delegate to
Lightstreamer the visualization of the data on the page. The class contains
the subscription details and the event handlers that allow
Lightstreamer to display the real-time data.
A specialized (derived) object, rather than a VisualTable object, should
be created and used.
The visualization of pushed values is performed by associating
a screen table (i.e. a set of HTML cells defined in the page) to the
data table, in a way that depends on the specific type of data table.
Several visualization actions can also be performed through the provided
event handlers.
The class constructor, its prototype and any other properties should never
be used directly; actually, VisualTable is not even defined as a global name.
Defined in lspushpage.js
|
Constructor Summary |
VisualTable
(<GroupDescriptor> tGroup, <SchemaDescriptor> tSchema, <String> tSubscriptionMode)
Used by the specialized data table objects to inherit the
basic support for all data tables whose visualization on the page is
managed by Lightstreamer.
|
|
Method Summary |
boolean
|
isPushedHtmlEnabled()
Inquiry method that gets the type of interpretation to be applied for
the pushed values for this data table.
|
void
|
setClearOnAdd(<boolean> clear)
Setter method that enables or disables the clearing of the screen table
assigned to the data table when the data table is brought to "running"
state, through PushPage.addTable().
|
void
|
setClearOnDisconnected(<boolean> clear)
Setter method that enables or disables the clearing of the screen table
assigned to the data table as soon as the connection with Lightstreamer
Server is lost.
|
void
|
setClearOnRemove(<boolean> clear)
Setter method that enables or disables the clearing of the screen table
assigned to the data table after the data table is reset to "inactive"
state, through PushPage.removeTable() or, implicitly, through
PushPage.addTable() for the same screen table.
|
void
|
setPushedHtmlEnabled(<boolean> enable)
Setter method that enables or disables the interpretation of the pushed
values as HTML code.
|
void
|
showValues(<ItemDescriptor> item, _values)
Operation method that sends a data row directly to the associated
screen table.
|
| Methods inherited from class Table |
getSchema, getGroup, setDataAdapter, getId, setSelector, setItemsRange, setRequestedMaxFrequency, setRequestedBufferSize, setSnapshotRequired, onItemUpdate, onLostUpdates, onEndOfSnapshot, onStart, getClassName
|
VisualTable
VisualTable(<GroupDescriptor> tGroup, <SchemaDescriptor> tSchema, <String> tSubscriptionMode)
Used by the specialized data table objects to inherit the
basic support for all data tables whose visualization on the page is
managed by Lightstreamer.
Parameters:
tGroup - A group descriptor object, which identifies the items that provide values for the data table rows. 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 that represent the data table columns. An Array of field names or a String schema identifier can also be used directly, instead of a schema descriptor object.
Note that, in case a SchemaListDescriptor or an array is used, a LiteralBasedProvider or equivalent Metadata Adapter is needed on the Server in order to understand the subscription request.
tSubscriptionMode - the subscription mode for the items, required by Lightstreamer Server. Permitted values are: - MERGE
- DISTINCT
- RAW
- COMMAND
isPushedHtmlEnabled
boolean isPushedHtmlEnabled()
Inquiry method that gets the type of interpretation to be applied for
the pushed values for this data table. In fact, the values can be
put in the target cells as HTML code or as text.
Returns:
true if pushed values are interpreted as HTML code, false otherwise.
setClearOnAdd
void setClearOnAdd(<boolean> clear)
Setter method that enables or disables the clearing of the screen table
assigned to the data table when the data table is brought to "running"
state, through PushPage.addTable(). The same setting is
used to clear the table during a reconnection in case such table was
in the "running" state during the disconnection.
Such clearing action may be requested, for example, if the same screen
table had been previously used to display a different data table.
Some kinds of data tables require that the screen table is cleared
before displaying data coming from the data table.
This applies MetapushTable, DynaMetapushTable
and MultiDynaMetapushTable. With data
tables of these kinds, this setting is ignored and the screen table contents
are always cleared upon reuse of a screen table for such a data table.
Lifecycle: This policy can be set and changed at any time.
Each time the data table is brought to "running" state through
PushPage.addTable(), or a reconnection occurs
after a disconnection that occurred while this table was already "running",
the current policy is used.
Parameters:
clear - true/false to enable/disable cells clearing when the data table is brought to "running" state.
setClearOnDisconnected
void setClearOnDisconnected(<boolean> clear)
Setter method that enables or disables the clearing of the screen table
assigned to the data table as soon as the connection with Lightstreamer
Server is lost. This applies both to disconnections requested by
changing the client Engine status and to disconnections caused by
connection problems. When this happens, the data tables currently
in "running" state are cleared and reset to "inactive" state;
in this moment, a clearing action may also be requested on the screen
table, in order not to leave outdated data in the HTML cells.
Note that, upon disconnection, the data tables currently added
to the page manager are not removed from the "running" tables set, so
that, after successful reconnection, they can be automatically brought
to "running" state again; in that moment, a screen table clearing will
also take place, unless prevented through the setClearOnAdd()
setting of the data table.
Lifecycle: This policy should better be set and changed
while the data table is in "inactive" state, as a disconnection may
occur during "running" state at any moment.
Parameters:
clear - true/false to enable/disable cells clearing on disconnection.
setClearOnRemove
void setClearOnRemove(<boolean> clear)
Setter method that enables or disables the clearing of the screen table
assigned to the data table after the data table is reset to "inactive"
state, through PushPage.removeTable() or, implicitly, through
PushPage.addTable() for the same screen table.
Such clearing action may be requested, for example, in order
not to leave garbage data in the HTML cells. A clearing of the screen
table will, however, take place as soon as a different
(or the same) data table is brought to "running" state and associated
to the screen table, unless prevented by the setClearOnAdd()
setting of the new data table.
Note that, when updates filtering is requested, the updates for
different items are not synchronized. This
means that there is no guarantee that an update for item A, received
after an update for item B, is indeed carrying data that was sent to
Lightstreamer Server by the Data Adapter after the data for B. So, when
the data table is reset to "inactive" state,
the data left in the cells may not be updated at the
same reference time across all items in the data table.
Note that, as stated before, if a row in a screen table is not cleared
after the associated data table is reset to "inactive" state, then it
may be cleared in the context of a different data table, eventually
brough to "running" state on the same screen table. When this happens,
any notification of the change in row values will be sent to an event
handler of the latter data table, not the former.
Lifecycle: This policy can be set and changed at any time.
Each time the data table is reset from "running" to "inactive" state,
through PushPage.removeTable() or, implicitly, through
PushPage.addTable() for its currently associated screen table,
the current policy is used.
Parameters:
clear - true/false to enable/disable screen table clearing when the data table is reset to "inactive" state.
setPushedHtmlEnabled
void setPushedHtmlEnabled(<boolean> enable)
Setter method that enables or disables the interpretation of the pushed
values as HTML code.
E.g.: if the value "<a href='news03.htm'>Click here</a>"
is received and HTML interpretation is enabled, then the target cell
will contain a link; otherwise it will contain this bare text.
Note that the setting applies to all the cells in the associated screen
table. Anyway if it's not the content of a cell that is going to be updated,
but one of its properties, then this setting is irrelevant for such cell.
VisualTable.prototype.WARNING = When;turning HTML interpretation on, make sure that no
malicious code will be pushed by the Data Adapter (for example through
the injection of undesired JavaScript code).
Lifecycle: This policy can only be set while the data table
is not in the "running" state.
Parameters:
enable - true/false to enable/disable HTML interpretation for the pushed values.
showValues
void showValues(<ItemDescriptor> item, _values)
Operation method that sends a data row directly to the associated
screen table. The data row is displayed on the screen table as though
it was received from the Server. This means that the supplied values
are submitted to the proper "onChangingValues" event handler, where
they can be formatted and the stylesheets and visual effects for the
target HTML cells can be customized.
However, the supplied values are not sent to
the internal data table, so they will not be retrieved as old values
in the next Table.onItemUpdate() event handler call.
In case the data table behaves with a "COMMAND logic",
the support for showValues is limited to updating existing rows.
This means that the special field carrying the "command" should
be set to "UPDATE" and the special field carrying the "key" should
contain a currently existing key.
Lifecycle: This operation can be requested only while the
data table is in "running" state.
Parameters:
item - an item descriptor object for an item in the data table. A String item name or a Number representing an item position can also be used directly, instead of an item descriptor object.
values - An object containing the association of the row fields to the corresponding values in the form: values[key] = value, where key is a FieldDescriptor object and value is a String. A String field name or a Number representing a field position can also be used directly, instead of a field descriptor object, as a key.
Cells for which corresponding fields have not been included will be left unchanged (i.e. the default value received by calling getFormattedValue in the onChangingValues event handler will be null).
In particular, values can be an Array. In this case, Array elements should be stored by starting at index 1. Note that Javascript arrays implicitly start with a 0 index. For example, if values is defined by the literal ['v', 'w', 'x'], then values[1], which is 'w', is the value used for the first field and 'v' is not considered.
Lightstreamer HTML Client API
Documentation generated by
JSDoc on Tue May 22 11:46:54 2012