writecontent

The Axiell WebAPI has built-in functionality to write images. To use this functionality, the server manager must have set up an "image handler" using he adlibweb.xml parameter file. Images are stored using the writecontent command. To write an image, the caller needs to provide at least the name of the server in the server argument, the image identifier (under which name the image will be stored) in the value argument, and the actual bytes constituting the image to be written.
Although we recommend that all images to be linked to Axiell Collections records be stored in a single folder, it is in principle possible to write images to sub folders of some main images folder, by entering a partial path in front of the image file name. However, note that the Axiell Designer Storage path option (which may have been set for an image field in the .inf) conflicts with having a hierarchical target folder for images. See the Grouping your images in subfolders paragraph in the WebAPI documentation about the adlibweb.xml file, the Media plugins documentation and the Axiell Designer online Help about the Storage path and Retrieval path options for more information.

Syntax

command=writecontent&<parameter>=<value>&...

• server (String) name of the image server to store content on.
• value (String) identifier of the digital content to be stored (i.e. a file name, or a file name preceded by a partial path).
• bytes (String) [implicit in storage and retrieval path URLs for both Axiell Collections and Adlib for Windows applications, so don't use it in those URLs] string of bytes constituting the actual file in binary format send along with the request using the http POST method.
• zoomify (Boolean) [optional] zoomify=true creates an image folder with so-called Zoomify files, specific to one image. These files can be used by the Zoomify API to allow for the possibility to view the relevant image interactively in all kinds of ways (by means of zooming in and panning), via the Zoomify viewer in your Axiell WebAPI application. See www.zoomify.com for more information.
  In this case, the server argument must contain the name of the image server to retrieve content from, while value is now the identifier of the digital content to be used (i.e. the file name of an image).
  In the imageServerConfiguration section of adlibweb.xml, an extra setting has to be made for this option, namely: <zoomifyPath>path-to-my-zoomify-folder</zoomifyPath> e.g. <zoomifyPath>c:\adlib\images\zoomify</zoomifyPath>. Later on, in this folder, any created Zoomify files will be saved in their own sub folder per image. The sub folder will get the name of the image file.
  By using the zoomify parameter in your writecontent request, wwwopac.ashx will call the Zoomify API which creates the sub folder and all Zoomify files.
• folderId (Integer) [optional] must be filled with the record number of the reproduction record to which the digital content must be written, if you are using an enterprise solution in which each branch of your organisation uses its own images folder and dataset in a common reproductions database. In that case, image file names might not be unique, so the WebAPI also needs to know to which images folder the image must be written. The record number of the relevant reproduction record provides this information, albeit indirectly because it allows the api to match the record number with an appropriate record number range specified for one of the datasets of the reproductions database, via the <folderMappingList> in the image server specification in adlibweb.xml, which specifies the lower and upper record number limits for all branch reproduction datasets and their associated branch-specific folders containing the images.
  This functionality was introduced October 2016.

- no URL request-specific description available (since this method cannot be used for writing content) -

- no Adlib.Data-specific syntax or examples available yet -

- no jQuery-specific syntax or examples available yet -