• Replies 17 replies
  • Subscribers 0 subscribers
  • Views 75 views
  • Users 0 members are here
Options
3sides - Social sharing widget
Related

Display iSheet Data on Home Page/Wiki

Sean Pillai
27343

I recall that there is a simple way to display iSheet records on a site's home page (or wiki) in a table or single-item format.  I'm referring to data from each individual row as opposed to charts and other aggregate data visualizations.  However, I haven't been able to find the instructions.  Any assistance would be appreciated.  I'm trying to display iSheet data in a more user-friendly manner by, for example, placing the contents of each column in a separate row, with each iSheet row corresponding to a separate table on the home page/wiki.

 

Simplified example:

(1)  This is my iSheet record:

 

Client Name Client Jurisdiction Client Code Client Mailing Address Client Relationship Manager(s)
Acme Co. Delaware 1234567 123 5th Ave., New York, New York Bob Smith; Amy Jones

 

(2)  I'd like to generate the following on the home page/wiki (including a link at the bottom that would allow the user to edit that particular record):

 

Client Name Acme Co.
Client Jurisdiction Delaware
Client Code 1234567
Client Mailing Address 123 5th Ave., New York, New York
Client Relationship Manager Bob Smith; Amy Jones

Edit Record [THIS LINK WOULD TRIGGER AN EDIT OF THE RECORD

 

]]>

  • There isn't a way to just drop an isheet on the home/wiki page (as a widget) as far as I'm aware, though it would be a really useful feature. The only ways to get it is either export XML with custom coding, REST API with custom coding or iframe (with some dynamically injected css to hide other parts of the page).

    The edit record button is also possible by opening a popup window to the isheet page with a url param to filter the item to the 1 item by its ID, and then inject JS in the popup to click the edit button. You can then use the jquery object from the popup to monitor for certain ajax requests (or if the edit modal is closed) to run events like onsave, onclose, etc... Hopefully they make a nice utility function for this (and view/add) one day.

    There actually is some JS code using highq libraries you can use to open the edit modal on the same page, but it is volatile in the sense that it could just change one day, plus its has some side effects.

  • I just implemented this today although my iSheet has multiple rows. I used JavaScript to call the iSheet API (/api/3/isheet/{iSheetID}/items).

    The column names are in the of the returned data object so I used the following:

    data.documentElement.getElementsByTagName("head")[0

    and looped through the nodes to obtain the column names.

    The contains the iSheet items and each item has multiple column values. (In your case you only have one item).

    I looped through my items using:

    dataItems = data.documentElement.getElementsByTagName("data")[0].childNodes;

    and then in a nested loop, I looped through the columns:

    dataColumns = dataItems[r].childNodes;

     

     

     

     

     

    ]]>

  • I am attaching an example of my end result (using sample data).

  • Hi Steve Mann, when you say "I used JavaScript to call the iSheet API", I assume you mean from a NodeJS server, or a client-side stub that calls a proxy (API) service? Otherwise it would mean you are exposing your secret key (to generate a token) on the client-side. This is a big No-No, and would fail any security audit, voiding any (cyber)security framework/ISO 27001.

    -----

    Aside from this, for info to others reading this thread: If you add "application/json" to the Accept header of the API request, then the response will be JSON which, for JavaScript, is much easier to consume and process than XML. Normally JSON would also be slightly more performant than XML in that the payload is smaller - no closing tags inflating payload size, however, the Collaborate API's format the response JSON with spaces, the result being that the responses are larger than XML responses!! The other plus side to XML is that you can walk back up the parent/child hierarchy, which you can't with JSON, i.e. you can't ask a child (key/value pair) what it's parent is.

    EDIT: Correction, Collaborate API's do not format the raw (JSON) responses, so these responses are smaller - approx. half the size of XML - which makes a difference with larger iSheet result sets. If you are used to using XPath or similar with XML, you can include JSONPath to perform something akin to this with JSON data.

    Another tip is that if you have the XML response, you can load this into JQuery using (assuming we're in Collaborate):

    var $xml = $j($j.parseXML(xmlResponse));

    We can then use JQuery selectors, as we normally would, to get at the nodes, e.g.

    // column headings
$xml.find("columnvalue").map(function() { 
   return $j(this).text();
});

// data
var $data = $xml.find("item").map(function() {
	return $j(this).find("column").map(function() {
		var $column = $xml.find("headcolumn[columnid=" + $j(this).attr("attributecolumnid") + "
    ); switch($column.attr("columntypealias")) { case "SHEET_COLUMN_TYPE_CHOICE": return $j(this).find("displaydata label").text(); case "SHEET_COLUMN_TYPE_LOOKUP": return $j(this).find("displaydata email").text(); default: return $j(this).find("displaydata value").text(); } }); }); // e.g. output to console - converting JQuery containers to standard arrays console.table($data.toArray().map(function(el) { return $j(el).toArray(); }));

    All that being said, the easiest way to get at iSheet data from within Collaborate (via Javascript) is to use the ExportXML link, shown in the top part of the iSheet Admin Module when you edit an iSheet View - though this approach does not return useful information for File/Folder/Image/Attachment columns, and it will need paging for large result sets. But at least you don't need to mess about with API access tokens, and creating proxy services.

    Andrew

    ]]>

  • Ryan D'Souza You mention "There actually is some JS code using highq libraries you can use to open the edit modal on the same page"... Can you point me to those? I'd love to experiment with them! Thanks very much! cc: Mark Salamon

  • Dan Pryor, type AddSheetItemCollection.editItem into the console. As mentioned, these are HighQ functions, not public interfaces, and can change at any release point. You need to firstly accept that risk (as a team) before relying on future solutions that use these  functions.

    In terms of the side effects spoken of previously, this particular function assumes you are in the iSheet (Home) Module. If you are not, there could be resources or other code missing it needs, and you'll need to overcome those obstacles.

  • Andrew Quinn I see that now when you look at the code. It's like this: AddSheetItemCollection.editItem(itemID,siteID,sheetID,viewID). And similarly: AddSheetItemCollection.viewItemModal(itemID). Another thing to be on the lookout for is that the user may not have edit rights to the item. I don't know if the edit form will work but will fail on submit or if the dialog won't load.

  • Mark Salamon, it will most likely result in an ERROR_PERMISSION header being sent back with the response, which in turn leads to a redirect to the horrid Access Restricted page. Same if user does not have access to site, sheet, or view.

  • Really appreciate it Andrew.

  • Mark Salamon / Dan Pryor, there are ways you can query whether the user has access, without the "Access Restricted" scenario dumping the user into a UX cul-de-sac. There is a checkContentAccess.action AJAX resource that can tell you whether the user has access to the site/sheet/view. However, when it comes to whether the user has access to an iSheet item, and has edit permissions, here we can use the itemRenderGridXML.action AJAX resource, which is what Collaborate uses to render iSheet views. I've attached an example of what an iSheet Utils library might look like, and how we can use these resources when invoking our AddItem / EditItem functions. Note: I've used JQuery Defers here instead of Promises so that this works in IE without poly-filling, however, I would always recommend using Promises over Defers, and poly-filling if required.

    Example calls to the attached library:

    // Example of calling the addItem
CommunityExamples.Sheet.addItem({
   siteID: 99,
   sheetID: 990
}).done(console.log).fail(console.error);

// Example of calling the editItem
CommunityExamples.Sheet.editItem({
   siteID: 99,
   sheetID: 990,
   sheetViewID: 991,
   itemID: 9999
}).done(console.log).fail(console.error);

// we can check access to site/sheet
CommunityExamples.Sheet.checkContentAccess({ 
   siteID: 99,
   sheetID: -990
}).done(console.log).fail(console.error);

// or to the site/sheet/view
CommunityExamples.Sheet.checkContentAccess({
   siteID: 99,
   sheetID: 990,
   sheetViewID:-999999
}).done(console.log).fail(console.error);

// check access to a particular iSheet item
CommunityExamples.Sheet.checkItemAccess({
   siteID: 99,
   sheetID: 990,
   sheetViewID: 991,
   itemID: 9999
}).done(console.log).fail(console.error);

// or not
CommunityExamples.Sheet.checkItemAccess({
   siteID: 99,
   sheetID: 990,
   sheetViewID: 991,
   itemID: -9999
}).done(console.log).fail(console.error);

// has edit permissions on iSheet item
CommunityExamples.Sheet.checkItemAccess({
   siteID: 99,
   sheetID: 990,
   sheetViewID: 991,
   itemID: 9999,
   access: {
      edit: true
   }
}).done(console.log).fail(console.error);

    Andrew