Query the group-/schema-list within a VisualTable instance?

hofmanna

Is there a way to query a VisualTable object for the group- or schema-array it handles, i.e. which items and fields are included in the table? I couldn't find any way in the documentation, so I thought I'd just ask here.

As to why I'm asking this - we originally based our implementation of the Lightstreamer JavaScript library within our sites on the supplied demos when we started using Lightstreamer, especially the Stock list Demo, as it came quite close to our use case. In the demo both the fields in the schema and the items in the group are explicitely supplied to the "OverwriteTable" object, and that's the way we've been doing it, too.

Only recently did I notice a little detail in the documentation for the constructor of "OverwritableTable(tGroup, tSchema, tSubscriptionMode)":

Parameter tGroup:
[...] A null value is also allowed. In this case, the names for the items should be supplied by the associated screen tables; hence, item names should be used in the cells as item descriptors. [...]
Parameter tSchema:
[...]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. [...]

This implicit setup of the schema and group is used in the Basic Stock List Demo, too.

For us this means that we could just use "null" for both parameters, as the HTML cells exist anyway and are sufficient to define both the schema and the item-group implicitely. This way we could leave out redundant information (schema/group information in both HTML and JavaScript), and simplify the logic for our websites on the server side when we dynamically create HTML cells whose content will be updated by Lightstreamer (no need to remember the schema and items when we build the HTML content).

So I'd really like to use the implicity definition of schemas and groups.. - but there's one rather big catch. If I don't explicitly specify the schema-fields and the group-items I neither have any idea what fields the schema really contains, nor which or how many items are within the table - but this may be information that's essential for some functionality on the website.

Of course the respective itemName and the available fields are available within the "onItemUpdate"- and "onChangingValues"-callbacks, but what if I need to know if a particular item is included in the table even before the first update arrives, because I need to change some JavaScript logic if it is? As long as there's no update for that particular item I don't know that it's there.

Knowing the actual schema of the table could be even more interesting, as otherwise I have no way to know which extra fields have been defined in the HTML cells and can be used via "VisualUpdateInfo.setFormattedValue()".

To make a long story short - it would be great if I could do something like this:
[SYNTAX="JS"]...
var myOverwritableTable = new OverwriteTable(null, null, 'MERGE');
var myItemArray = myOverwritableTable.getGroup();
var myFieldArray = myOverwritableTable.getSchema();
...
[/SYNTAX]
Is this already possible, and I just overlooked the corresponding entry in the documentation? If not, I'd really be interested in your thoughts about this, and why there's no way yet to access this information. The table knows all these details already anyway, so all it'd take would be to add some public interface to access this table-internal information.

Mone

Hi,

you're (as usually :Smile_Ab: ) right, such getters are not available.

we're valuating to include them in our next release, btw in any case, if we add such getters, note that, for "null,null"-constructed tables, you can't use them before the addTable call is issued as that call is where the table object is bound to it's html counterpart so that it can read it's group and schema from the DOM.

hofmanna

@Mone, Wrote: we're valuating to include them in our next release, btw in any case, if we add such getters, note that, for "null,null"-constructed tables, you can't use them before the addTable call is issued as that call is where the table object is bound to it's html counterpart so that it can read it's group and schema from the DOM.

Oh, yes, of course, I missed the call to "PushPage.addTable()" in my few example lines, thanks for the hint.

Nevertheless I think the getters should be "usable" even before "addTable()", i.e. they would just return "null". If you say "..can't use them before.." it sounds as if that would result in an error, so I just wanted to clarify this point.

Furthermore, I can use Table.getId() to find out if the table has been added (i.e. is in running state), so I could do something like[SYNTAX="JS"]var myOverwritableTable = new OverwriteTable(null, null, 'MERGE');
var myItemArray = null;
var myFieldArray = null;
...
//addTable() might(!!) be called inbetween
...
getGroupAndSchemaIfTableIsRunning();
...
function getGroupAndSchemaIfTableIsRunning() {
if (myOverwritableTable.getId() != null) {
// table is in running state, "addTable()" has been called
var myItemArray = myOverwritableTable.getGroup();
var myFieldArray = myOverwritableTable.getSchema();
} else {
//schedule next check
window.setTimeout("getGroupAndSchemaIfTableIsRunning()",2500);
}
}
[/SYNTAX]IMHO it would be even better if there were dedicated callback interfaces similar to "onStart()", something in the line of "onAdd()" and "onRemove()", because if I'm not mistaken "onStart()" is not necessarily called right away after the "addTable()"-call finishes, but only after the the Lightstreamer server has received and answered the subscription-request. This would mean that "onStart()" wouldn't be called if there's a network problem, even though the HTML cells have been processed by the "addPage()"-call, so the table-objects knows which fields and items the table contains.

And as far as I can tell there's no way at the moment to get notified if a table is removed via "removeTable()", not even a counterpart to "onStart()" like "onStop()".

But if there were "onAdd()" and "onRemove()" callbacks I could just use them like this :Smile_Ah: SYNTAX="JS"]var myOverwritableTable = new OverwriteTable(null, null, 'MERGE');
myOverwritableTable.onAdd = function() {
var myItemArray = myOverwritableTable.getGroup();
var myFieldArray = myOverwritableTable.getSchema();
};
myOverwritableTable.onRemove = function() {
var myItemArray = null;
var myFieldArray = null;
};[/SYNTAX]..and I'm done.

By the way, I just noticed that the "onStart()"-callback has no parameter - wouldn't it be a good idea to hand a reference to the table-object to the called function, i.e. change the "onStart()"-definition from

void onStart()

void onStart(<Table> tableSpec)

That way you could use one central function to handle all the "onStart()"-callbacks, and choose different actions depending upon the table id or even the class of the table (by using "getClassName()") :Smile_Ah: SYNTAX="JS"]function myOnStartHandler(tableSpec) {
switch (tableSpec.getClassName()) {
case "OverwriteTable":
if (tableSpec.getId() == 'myTableName') {
...
} else {
...
}
break;
case "DynaScrollTable":
...
break;
}
}
...
myOverwritableTable.onStart = myOnStartHandler;
...[/SYNTAX]At the moment you have to specify separate functions as there's no indication for which table instance the "onStart()" callback has been called.

Oh, there's one other question I have regarding "addTable()" and "removeTable()" (sorry, quite a lot for one post, I know). When I call "addTable()" the first time, the library scans the DOM for the HTML elements to associate the table to. But when I do something like this over the lifetime of the page :Smile_Ah: SYNTAX="JS"]var myOverwritableTable = new OverwriteTable(null, null, 'MERGE');
...
//first call to 'addTable()'
myPushPage.addTable(myOverwritableTable, 'myTableName');
...
myPushPage.removeTable('myTableName');
...
//second call to 'addTable()'
myPushPage.addTable(myOverwritableTable, 'myTableName');
...
[/SYNTAX]..what happens during the second call to 'addTable()'? Does the Lightstreamer library remember that it already searched through the DOM for that particular table identifier, or is the DOM-search repeated? This would be good to know for the use-case of manipulating the DOM via JavaScript, i.e. adding another table row dynamically..

Mone

Nevertheless I think the getters should be "usable" even before "addTable()", i.e. they would just return "null". If you say "..can't use them before.." it sounds as if that would result in an error, so I just wanted to clarify this point.

right

IMHO it would be even better if there were dedicated callback interfaces similar to "onStart()", something in the line of "onAdd()" and "onRemove()", because if I'm not mistaken "onStart()" is not necessarily called right away after the "addTable()"-call finishes, but only after the the Lightstreamer server has received and answered the subscription-request. This would mean that "onStart()" wouldn't be called if there's a network problem, even though the HTML cells have been processed by the "addPage()"-call, so the table-objects knows which fields and items the table contains.

And as far as I can tell there's no way at the moment to get notified if a table is removed via "removeTable()", not even a counterpart to "onStart()" like "onStop()".

you don't need such events as:
onAdd would be fired during the addTable execution that's called by you
onRemove would be fired during the removeTable execution that's called by you
onStop would be fired just before an onStatusChange("DISCONNECTED") event or before an onEngineLost() one, so that you already have a place to hndle such event.

In conclusion I think that, at least for the moment, those events will not be included.

By the way, I just noticed that the "onStart()"-callback has no parameter - wouldn't it be a good idea to hand a reference to the table-object to the called function, i.e. change the "onStart()"-definition from [...]

you can use the this from inside the onStart callback to check wich table you're processing
[syntax="JS"]function myOnStartHandler() {
switch (this.getClassName()) {
case "OverwriteTable":
if (this.getId() == 'myTableName') {
...
} else {
...
}
break;
case "DynaScrollTable":
...
break;
}
} [/syntax]

..what happens during the second call to 'addTable()'? Does the Lightstreamer library remember that it already searched through the DOM for that particular table identifier, or is the DOM-search repeated? This would be good to know for the use-case of manipulating the DOM via JavaScript, i.e. adding another table row dynamically..

The library does the search on the DOM each time the addTable is called, so you can remove a table, change the html and re-add the same "null-null" table resulting in a table with a different group/schema.
The only exception is if you give a ScreenTableHelper to the PushPage. In such case the DOM is never searched, so, to change the group/schema of your "null-null" table, you should, remove the table, add new cells to the ScreenTableHelper instance and re add the table.

HTH