Allow multiple manipulation operations in one link

[jacobwindsor]

Currently, you can only do one manipulation per link. It would be useful for some users to do multiples at once. For example, zooming on a group of nodes and highlighting one of them at the same time.

The syntax for this could be something like

[some text]!!zoomOn 'node1,node2,node3' | toggleHighlight 'node2' 'red!!

The | pipe denotes the seperation of manipulations to perform.

What would the RegEx for this be?

[ariutta]

I took a look at several formats to see how they might be related to this issue, as you can see in Reference Examples below. Just brainstorming, here are a few more ideas to play around with:

• Just use a WYSIWYG visual editor (no markdown)
• Extend Commonmark w/ S-expressions for key value pairs (key: string, value: entries before next string)
  ** Option using !! as delimiter (rough code):
  [some text]!!(zoomOn (node1 node2 node3) toggleHighlight (node2 red) (node3 yellow))!!
  ** Option using KS as namespace (rough code):
  KS[some text](zoomOn (node1 node2 node3) toggleHighlight (node2 red) (node3 yellow))
• Extend Commonmark with a variation on SLIM attribute merging
  ** KS[some text](zoomOn="node1, node2, node3" toggleHighlight="node2 red, node3 yellow")
• Extend Commonmark with a CSS-like syntax
  ** KS[some text](zoomOn {nodes: node1, node2, node3} toggleHighlight {node2: red; node3: yellow})
• Extend Commonmark with querystring-like syntax
  ** KS[some text](zoomOn=node1,node2,node3&toggleHighlight=node2,red;node3,yellow)
• Extend Commonmark with JS-like syntax
  ** KS[some text](zoomOn(node1, node2, node3) toggleHighlight({node2: red}, {node3: yellow}))
• Extend Commonmark with JSON
  ** KS[some text]([{"zoomOn": ["node1", "node2", "node3"]}, {"toggleHighlight": [{"node2": "red"}, {"node3": "yellow"}]}])

Reference Examples

Commonmark / GF Markdown

• Link [demo](http://github.com) demo
• Link w/ title (hover to view) [demo](http://spec.commonmark.org/0.26/#example-456 "see spec") demo
• Image ![img description](/logo.png)
• Image w/ alt text ![img description](/logo.png "some alt text")

Wikitext

• large red text {{color|red|{{{resize|150%|text}}}}

Lean versions of HTML

Check your browser console to see the output from the following formats.

SLIM (live)

p onClick="c(zoomOn('node1,node2,node3'), toggleHighlight('node2', 'red'))" clickme

HAML (live)

%p(onClick="c(zoomOn('node1,node2,node3'), toggleHighlight('node2', 'red'))") clickme

Pug (live)

p(onclick='c(zoomOn("abc,def,hij"), toggleHighlight("abc", "red"))') clickme

[ariutta]

One item to consider regarding the pipe: on the Linux command line, that indicates that the result of the previous operation is passed to the next. If that's not true in this case, could it be confusing? If so, we could consider using another symbol like &.

[jacobwindsor]

Thanks for taking a look 😄

WYSIWYG

Personally, I prefer this option over any Markdown in terms of UI. I think the manipulation operations are just too lengthy for Markdown. However, the issue is development time...

The markdown option is so easy to develop and unit test. It's also so easy to integrate into WPs. You can keep the backend storage of descriptions the same and just use jQuery to parse the Markdown.

Extending Commonmark

Any extensions to Commonmark should be easy to understand and easy to remember. The latter is harder since some manipulation operations need many parameters and the order of them is crucial. For example,

[some text]!!zoomOn 'node1' 'others'!! // easy to remember

[some text]!!toggleHighlight 'node1' 'red' 'others'!! // harder to remember because of the extra parameter.

Your ideas

• I like the namespace. I'd suggest just K though.
• Querystring and JSON are hard to understand. Maybe even overwhelming for non-devs. However, I do like that each parameter is named so order doesn't matter.
• SLIM attribute merging is visually the most pleasing and approachable I think. However, it does have the same issue of requiring a specific parameter ordering.
• CSS-like syntax is less visually pleasing because of the {}. But... the attributes can be named.
• JS Syntax works well but only if there is one parameter per call. There are a lot of brackets though and it's easy to forget closing them!
• I don't think lean HTML is an option since it's too difficult to understand for non-devs.

Mistake(?) in CSS and SLIM examples

• Small thing: in your example the specification of toggleHighlight is wrong. Every node in the list is highlighted one color.
• To achieve the behaviour in your example you'd had to do:
  toggleHighlight {nodes: node2; color: red} toggleHighlight {nodes: node3; color: yellow}
• I've opened this issue to discuss this further.

Just one parameter

Thinking about everything, the issues really come when there are multiple required parameters. In all of the manipulation functions, there is a resets object as a parameter. For toggleHighlight this is:

{others: boolean, hidden: boolean, panZoom: boolean}

I integrated this since it's really needed when you can't do multiple operations in Markdown. However, with multiples enabled you may as well just do (in JS-like syntax):

K[some text](zoomOn(node1, node2, node3) toggleHighlight({node2: red}, {node3: yellow}) resetPanZoom(node1) resetHidden(node2) resetHighlighted(node1,node2))

Where the parameters to the resets are entities that are excluded from resetting.

Relating to this issue, if we only allow one parameter per manipulation method then we must use the alternative syntax.

[ariutta]

Yeah, I was wondering about that toggleHighlight syntax.

I'll have to think about this a bit. Do Egon or the other researcher you're working with have any preferences?

BTW, I ran across another format called edn. Here's an online playground, in case you didn't get enough examples above. 😆

[jacobwindsor]

Related. Using a WYSIWYG -> markdown editor could solve these issues and also give the possibility for easy state tracking.

[jacobwindsor]

Done in #4