Find and Replace UI about ami

[patdunlavey]

Some ideas:

Looking at JSONPATCH, it seems like a plausible way, using the replace operation, to apply a change to a specific path in the json. It does not provide an ability to replace in the php sense of str_replace or preg_replace. Nor does it support wildcards in the path parameter. So it could only be used once we know the exact path to the value that we know we need to overwrite. The function of finding the values that need to replaced and returning the paths to them would need come from somewhere else.

My thinking is that this would be driven from a custom VBO operation that is the strawberryfield analog to the VBO "Change Values" operation. I'd maybe take it further to add "Add Values" and "Delete Values" options, and call it "Strawberryfield CRUD".

In a view which has our custom vbo action enabled, you select the ADOs for which you intend to perform the find/replace/add/delete, select the "Strawberryfield CRUD" operation, and click "Apply to Selected Objects". On the confirmation screen, a form would let you define

1. a JMES path (or possibly multiple JMESPaths, separated by commas), or something along those lines, to identify where the values are in the sbf json that you want to perform the find/replace/add/delete on.
2. A select list with the options: "Find and Replace", "Add", "Delete".
3. If Find/Replace or Delete is selected, show a field where you can define an optional find pattern, literal text or regex, perhaps with a checkbox indicating which.
4. If "Find/Replace" or "Add" is selected, show a new value string (with possibility for capture group token indicating where any capture groups from the find regex pattern would go).

I think these fields should be in a container labeled "Strawberryfield CRUD Operation", and it should be possible to instantiate additional copies of it on the form, so that you can perform multiple find and replace operations in the same bulk operation, as you can do with VBO's "Change Value" operation.

I can't think of a way to make this as user-friendly as VBO's change value operation, where the confirmation form lists all the available fields, with checkboxes that, when checked, expose a form for that field. I'm thinking, at least for a minimally viable product, that we simply provide instructions for use the ADO Tools tab on an object to find a JMESPath to the value you wish to CRUD.

The submit method for this form would loop as follows:

• Through each ADO
  • Through each Strawberryfield CRUD Operation, return the JSON pointers to each value that needs to be added, replaced, or deleted.
    • Through each JSON path, invoke JSONPatch with the appropriate operation and value on the JSON. (I think these can be batched into a single JSONPath json file and executed at once.)
  • Save the JSON when done with each ADO.

@DiegoPino

[patdunlavey]

One question I have is whether JMESPath supports returning JSON Pointers. From what I can find, it doesn't. It only returns an array of values. So bridging between JMESPath and JSONPatch could be a challenge. I like the idea of using JMESPath because it's used in numerous places in Archipelago, but maybe it won't work for this application?

[DiegoPino]

@patdunlavey sorry, late to this. There is a lot good stuff and some of this already is coded and can be tested, other things we may need to figure out how to implement. I would love to show you some of this with screenshots next week and share some code too.

Re: JMESPath supports returning JSON Pointers

This is a thing I have been planning on adding. As you correctly detected JSON Pointers depend a lot on knowing exactly where something is. A lot can be refined with the current search and replace view we ship (means you can pre filter using facets and search) but not all.

So, the way I see JMESPATH integration with JSON Pointers would be to either
1.- Extend the provided JSONPATCH syntax to take a finer JMESPATH query. Do the query internally using the JMESPATH and based on the response JSON, convert the query into multiple fixed JSONPOINTERS and execute them without user interaction. The good thing here is that we could do finer grained queries. The bad is we need to process them of course and also make sure only a subset of JMESPATH is possible (by either stripping parts or not allowing them), since JMESPATH can also "cast" results into arbitrary structures after the query and with that we could not build ourselves the JSONPOINTERS anymore
2.- Second option would be to allow a Pre JMESPATH query and apply pointers on the result, not the whole thing.

I'm confident that once I get over the Form API issue I have with adding Webform Elements as an option, that last one will be the preferred one for users. Graphical and more intuitive. Right now it renders the webform elements (one for selecting the source, another for the replacement) but it fails to pass the values in the form state, mostly because VBO wraps the config form in a strange way but also because I do not know better

better with screenshots and code next week, thanks!