Using Squiz Matrix to manage content that delivered externally as a JSON feed

(Bdebroglio) #1

Hi all,

 

We’re considering using Squiz Matrix to provision an external map with a JSON feed.

 

In Squiz Matrix, we’d like to be able to create and manage a bunch of points (each point having title, text and image, etc) … we imagine that each point can be an asset, with a bunch of metadata (easy) … then an asset listing could output JSON …?

 

The JSON feed would be called by an external application … the JSON feed could be publicly available.

 

What do we need to consider?

 

Can we send the appropriate HTTP header content type using Squiz Matrix?

(Anthony Barnes) #2

Can we send the appropriate HTTP header content type using Squiz Matrix?

 

You can find the details on headers here: http://manuals.matrix.squizsuite.net/designs/chapters/global-variables#content-type, just replace the example one with 'application/json' in your design file.

 

What do we need to consider?

 

You're approach is pretty standard with the listing and metadata.

 

Some tips:

  • You can use a data record asset type to hold the metadata. This asset has no content, functionality or dependent assets so it is quite 'light' to use (other side of the coin would be standard page which comprises of 3 other dependent assets).
  • Turn off all div presentation options in the listing bodycopies to make sure you don't accidentally produce HTML markup mixed in your JSON output
  • If you use asset listings to produce JSON output you will want to use a 'position format' with the value -1. This will give you a way to control the asset that appears last in the list and remove any trailing comma that might render your JSON invalid. It will result in some duplication but generally manageable.
  • If it doesn't need to be dynamic each time it's hit, ensure the listing is being cached (turn on Matrix cache configuration if it's not already). Cache is global so make sure you do this with some consideration to your overall caching strategy. Asset listings generally require a bit more processing than other asset types so reducing the work your system has to do is always a good thing and should speed things up for consumers.
  • Regarding the image, I would probably use a 'related asset' metadata field and using keyword replacements to output the url of the associated image asset (search for the 'as_asset' keyword modifier in the manuals). There are other ways to associate the image with the 'point', but I if the number of associated images is predictable and constant then metadata & keywords are probably the best way to go.

For long term maintenance and because you might be passing that url to 3rd party consumers I wouldn't use the asset listing url directly in your site. In the future you might wish to replace that functionality with a different method so instead use a paint layout to apply the listing to another asset type (with bodycopy div presentation turned to raw). Once you start handing that url out it can be difficult to ascertain who/what is consuming it without analysing server logs so that might be another thing to consider when setting it up.

(Bdebroglio) #3

Thanks Anthony, that's really helpful.

(Joel Porgand) #4

You might want to consider the maintenance burden you're introducing. Depending on the size of your dataset & the frequency of updates something like a csv datasource might be easier to maintain.  

(Bdebroglio) #5

J.P - scope is around 20 to 30 assets.

 

When you say a CSV datasource, do you mean writing to a CSV file (flat file)?

(Joel Porgand) #6

J.P - scope is around 20 to 30 assets.

 

When you say a CSV datasource, do you mean writing to a CSV file (flat file)?

 

Yeah. If you have a csv file you can add it to matrix as a CSV Datasource Asset, then use an asset listing to format it as JSON (or whatever). Squiz have gussied the csv datasource up a bit so you can even run basic queries against it. 

 

20-30 assets isn't so bad though, and for maintaining stuff like image links keeping everything in matrix makes more sense.