Hello -

There are multiple means of rendering a table in a "grid", from a simple html table populated with an SQL query, to ZEN "Grid" object

For the html table, the following code would give you a table from the SQL query


<script language=SQL name="query">
SELECT * FROM User.DataTable
</script>
<table border=1 bgcolor="">
 <tr>
 <csp:while counter=queryCol condition="(queryCol<query.GetColumnCount())">
  <th align=left><b>#(query.GetColumnHeader(queryCol))#</b></th>
 </csp:while>
 </tr>

 <csp:while counter=queryRow condition=query.Next()>
 <tr class='#($S(queryRow#2:"DarkRow",1:"LightRow"))#'>
  <csp:while counter=queryCol condition="(queryCol<query.GetColumnCount())">
   <td>#(query.GetData(queryCol))#</td>
  </csp:while>
 </tr>
 </csp:while>
</table>

 

For the ZEN example, take a look at your "local" sample page:  <localhost>/csp/samples/ZENTest.DynaGridTest.cls

In answer to the "Why?" questions...

Assume you have a generic "Person" record, and now you want to treat this "Person" as a "Doctor" record where Doctor is an Extension of Person. When the Person record was created, it was not known that this represented person was a going to be doctor record at some point in the future. The person record was created, properties set to values, and saved, linked referenced (i.e. "used" as a Person record). Now at some point later, there is a need to make a "Doctor" record out of this "Person" record. Since anything you could do with/to a Person record can be done with a Doctor record and Doctor only adds functionality (and possibly overriding methods), creating a "new" Doctor record and then replicating data values will not update any references to the "Person" record (and may not even be identifiable from just the Person record to begin with), but morphing that instance of a Person into an instance of a Doctor will preserve all of the references that might exist while enabling the new properties and methods of a Doctor.

Success!!!

I created a callable ZenMethod function that allows me to pass in the table component ID, the SQL Table name and the Row ID, that will jump the table to the correct page and row to match the ID passed in.


Method jumpTable(componentID as %String, tableName As %String, id As %String, pageSize As %Integer) [ ZenMethod ]
{
  set SQLtxt = "SELECT *, CEILING(%vid/"_pageSize_") PageNum, {fn MOD(%vid,"_pageSize_")} RelRowId FROM ( SELECT ID FROM "_tableName_") WHERE ID = "_id
  set sql1 = ##class(%ResultSet).%New()
  do sql1.Prepare(SQLtxt)
  do sql1.Execute()
  while sql1.Next() {
    set page = sql1.Get("PageNum")
    set row = sql1.Get("RelRowId")
  }
  set Table = %page.%GetComponentById(componentID)
  set Table.selectedIndex = (row-1)
  set Table.currPage = page
}

This then can be used for any table on any zen page.


Thanks

My problem is that my table (which *is* filled via an SQL) can have multiple pages of "displayed sub-sets" (i.e. the Page Size of the table, controlled by the Table Navigator), and when I launch the page directly with an instance ID passed by URL value, I can load the form, but I don't see anyway to figure out which page and which row to "jump to" and "select" programmatically. (my use case is relatively simple, as I don't have any client side filters or sorting that is done, just a "result set being displayed"