Preview: This is how you update metadata in IMatch 2017 scripting:

[Mario]

The IMWS embedded in IMatch can already update database objects. The stand-alone IMWS will learn that soon as well.

Like with most other IMWS features, I moved intelligence from the client (browser / app) into the server. This makes scripting easier and demands less from the programmer and client.

A typical operation is updating metadata. For example, you have somehow determined that the files with the id 1,2,3 need their rating changed to 3.

This is how you tell IMWS to do this:
You call the /metadata endpoint from your script and send this string:

id: "1,2,3",
tags: [
{
  tag: "rating",
  op: "set",
  value: 3
}
]


This is standard JSON syntax, which is the common text-based data exchange format used everywhere these days. Easy to understand., fast to process, flexible and powerful. IMWS uses this everywhere.

Another example: To change the XMP label of these files to red, you send this string:


id: "1,2,3",
tags: [
{
  tag: "label",
  op: "set",
  value: "Red"
}
]


You can also do this in one command. The tags parameter is an array (hence the [ and ]) and it takes any number of operations:


id: "1,2,3",
tags: [
{
  tag: "rating",
  op: "set",
  value: 3
},
{
  tag: "label",
  op: "set",
  value: "Red"
}
]


If you want to do this for all files currently selected in the file window, you use a so-called idlist instead of individual file ids.
See this page for more information about idlists

This command sets the rating to 3 and the label to "Red" for all files currently selected in the file window:

idlist: "@imatch.filewindow.selection",
tags: [
{
  tag: "rating",
  op: "set",
  value: 3
},
{
  tag: "label",
  op: "set",
  value: "Red"
}
]


To add the keyword "location|beach" to all selected files you send this command:

idlist: "@imatch.filewindow.selection",
tags: [
{
  tag: "hierarchicalkeywords",
  op: "add",
  unique: true,
  value: "location|beach"
}
]


The unique parameter tells IMWS to check for existing keywords and add the keyword only if it does not already exist (this is the default so the parameter can be skipped).
You can also add multiple keywords. The value parameter can be an array of strings:

idlist: "@imatch.filewindow.selection",
tags: [
{
  tag: "hierarchicalkeywords",
  op: "add",
  value: ["location|beach","vacation","family"]
}
]



To replace the typo in Grmany with Germany in the keywords of all selected files:

idlist: "@imatch.filewindow.selection",
tags: [
{
  tag: "hierarchicalkeywords",
  op: "replace",
  replace: "Grmany",
  with: "Germany"
}
]



To append the text "(est)" to the title tag of all selected files, you can do this:

idlist: "@imatch.filewindow.selection",
tags: [
{
  tag: "title",
  op: "append",
  value: "(est)"
}
]


To delete the description of all selected files, you just send:

idlist: "@imatch.filewindow.selection",
tags: [
{
  tag: "description",
  op: "delete"
}
]



How you fill the id or idlist depends on your script.
Maybe your script does a search operation first, to find all files matching a specific criteria.
Then you use the file ids from this search as the input for the metadata update operation.

This makes it very easy to do things like: "Find all files with... and then change the metadata like this..."

I think that this is easy to understand. And it's very flexible.
Performance is of course exceptional because all the work is done on the server (or by IMatch if you use this in a script running in IMatch).

I will design operations to update categories, collections or Attributes etc. in the same way.

[Jingo]

I've been waiting for something like this for YEARS.... can't wait to take it for a spin!!

[Mario]

I've been waiting for something like this for YEARS.... can't wait to take it for a spin!!

Yeah, well. This was always possible using IMatch scripting and the IMatch object model.

It's now just based on another technology (web service).
And I've packed a lot of intelligence into IMatch WebServices. This simplifies scripts, at least for many typical use cases.

The machine running the standalone IMWS usually has more power than the client running the script.
We always have to keep in mind that programming IMatch and the stand-alone IMWS server works the same.
The above commands allow you to update metadata in your local IMatch database, but also on a remote IMWS server in your basement or on the other side of the planet...

[Mario]

I have created a sample app which shows how to add, set, remove, update and append metadata.

Either directly via the /metadata endpoint, or manually. Manually means that the script reads the data of the files, manipulates it and then writes it back. This allows a script to do whatever it wants with the metadata.

This is how the sample looks (click to enlarge):



It's super-easy to create great-looking user interfaces with IMatch 2017 scripting, with minimal effort.
And they can be responsive, which means they can run from 8K monitors down to small smart phone screens!

And this means I can add more cool features to IMatch quickly, when doing it as an app. Awesome.

[Jingo]

Yeah, well. This was always possible using IMatch scripting and the IMatch object model.

Believe me - I tried and tried to understand how to code scripts for IMatch but trying to understand all the objects/functions was really frustrating.... when to use a catalog object and what methods/functions were available was hard to find - even with the chm files available.

Now that we can use html/javascript to easily access the database - things will be much easier.  Having framework examples on a) how to load data based on search into an itemlist  b) manipulate said files to access the metadata  and  c) a complete list of endpoints with examples on how to access will make things much easier to work with.

[Mario]

The IMatch 5 Scripting help is complete and very detailed IMHO. Every method is listed and explained, with examples how to use them, links to related info etc.
IMatch 5 includes over 20 sample scripts to demonstrate every aspect of the object model.
Plus several more complex scripts, like the VarToy, the CSV Import or the KML Exporter.

There is no significant change in how IMatch is programmed. With Basic, you used the IMatch Object Model. Now you use the endpoints provided by IMWS.
This cannot be 'simpler' because writing scripts which access a DAM system will always require a minimum degree of complexity. The same is true for writing apps or scripts in general.

You can get an impression already by looking at the sample scripts in the IMatch Anywhere Developer Center.

IMWS documents itself. You can access the documentation via the "Discover IMatch Anywhere" command in the IMatch WebViewer Gear menu.
This lists all available endpoints and their parameters plus examples you can run against your database.
This already exists and can be used right now.

How you use these endpoints in your script depends on the programming language you use.

[schwarzvogel]

Ich lese hier immer wieder "Imatch 2017" - meine Version 5.8.4 bezeichnet sich "auf dem aktuellen Stand"
Was bitte ist der Unterschied
mfG schwarzvogel

[Mario]

IMatch 2017 ist das kommende Upgrade, wie in der Ankündigung vor ein paar Wochen beschrieben.

Posts in Deutsch bitte in der Betreffzeile immer mit einem [GERMAN] einleiten. Das spart allen community-Mitgliedern, die kein Deutsch können, Zeit.

[sinus]

I have created a sample app which shows how to add, set, remove, update and append metadata.

this will be very cool.