Navigate to tiddler in click handler

[andrewgoz]

I've been working on a plugin for ApexCharts (also discussed recently elsewhere). The current work in progress can be found at:

http://www.scss.com.au/family/andrew/tiddlywiki/

It's progressing nicely, but I'm now trying to implement a click handler that will navigate to a specific tiddler. If you look at the recent "ApexChart Line Test" I've got a click handler that is doing what I want, except that I'm getting a warning about "$tw.wiki.addToStory()" being deprecated.

I've tried trawling through various object structures and properties looking for a "story" property, but I can't find it!

I'd like to do this the right way. Can anyone help?

[pmario]

Cool stuff. You should have linked to: ApexChart Line Test using the More -> Permalink option

[pmario]

I'd like to do this the right way. Can anyone help?

That's good. Do you have a github repository for this code? ...

I did have a quick look at the code and saw that there is some code in the plugin, that causes security issues. Since our users can modify tiddlers eval is evil. This needs to be fixed.

[pmario]

For the configuration options TW has core functions that can deal with socalled data-tiddlers, which will parse the config key:value pairs in a safe way.

And there is a tw core function which can do a deepMerge if needed. But I'm not sure if it is needed.

We will need to have a closer look at the code first. I only did skim it for about 3 minutes.

[pmario]

I did find this: https://apexcharts.com/docs/creating-first-javascript-chart/

Can you point me to the detailed info about the data-structure you want to support for the plugin. Or does the data structure depend on the chart-types and they are different for each chart-type?

IMO we should convert the complex "options" JSON structure into several simple elements, that our users can handle. TW data-tiddlers are only 1 level deep. So we have simple key: value stores. Users can handle them very well because of their simplicity.

I think the needed configuration can be handled that way. .. This would also eliminate the need for a try catch construction in the code.

[pmario]

I think I found them: https://apexcharts.com/docs/options/series/ ... ouch there are many of them.

I think we can create an "actions" configuration, that is bound to the click event-handler and executes a TW actions. We only need to make sure, that the events get the right infos.

I've seen the events have a chartContext object. So it may have access to all the options and data objects the chart is initialized with.

---- Waiting for your feedback, before I go on reading.

[andrewgoz]

The options data structure passed to ApexChart() is totally flexible and varies greatly between the chart types - it even contains the source data to be charted. For fancy charts there could be multiple data series.

I can't think of anything workable other than an eval, but I'm open to suggestions. I initially tried a JSON structure, but that isn't flexible enough. I don't see the problem with eval() anyway. Arbitrary code execution is a console click away...

I've already got my code set up so that the widget code can put variables into the options structure that can be later accessed by the click handler. That's how I get access to the wiki object now and call its deprecated addToStory().

From the console message it sounds like I need to access a story object from somewhere, then call its addToStory(). Possibly also needing to obtain the name of the 'from' tiddler as well, although that seems to be optional. I just can't see any objects accessible to the widget that produce a story object.

[andrewgoz]

I've made the message go away by creating a Story object in the widget js (new $tw.Story()), storing that in the options structure, then in the click handler calling that objects addToStory().

It seems a bit odd and a step backwards to be creating Story objects all the time. Maybe some other way is intended?

[pmario]

It seems a bit odd and a step backwards to be creating Story objects all the time. Maybe some other way is intended?

The story object is light weight and designed to be part of the lifecycle of a widget. The deprecated behaviour created the object on a per call basis, so it needed to be garbage collected after every call of the function. The existing behaviour should be more efficient.

TW supports several "story-rivers". So if a navigation is triggered, there should be a possibility to target a user specific one. Even if the functionality is not part of the widget from the beginning, it makes sense to use the internal functions. So extending should be easier.

Eg: If someone wants to use the widget with the MultiClumn Layout, which is a popular plugin for wide screens.

[pmario]

I can't think of anything workable other than an eval, but I'm open to suggestions. I initially tried a JSON structure, but that isn't flexible enough.

Hmmm, I'm a bit overwhelmed with the possibilities we have. May be your are too. I can see several ways to improve security and I also think functionality, maintainability and easy user experience.

I don't see the problem with eval() anyway. Arbitrary code execution is a console click away...

I do. We cannot compare physical presence with remote control of a computer. Especially if something declared as "data" is executed by a widget. Our users do not expect data to be compiled if they import tiddlers.

The TW import process shows a message, if executable tiddlers are imported. So the user has a chance to deny it, or have a closer look.

There is no warning for data tiddlers. So it's easy to hide malicious code in tiddlers that are configured as data.

---

The easiest way to create a usable js-object is to use the browser and Node.js native JSON.parse('{"key": "value"}') functions.
IMO that's the first step to make the widget more secure. See: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse

[pmario]

Having a closer look at your code, I think you already know the TiddlyWiki Dev Edition. I think it's a good source for developers. You should have a closer look, if you did not know it yet.

There is a Javascript Widget Tutorial which shows the different steps of a TW widget.

It seems you know that info too. right?

Reading the wikitext at: http://www.scss.com.au/family/andrew/tiddlywiki/#ApexChart%20Line%20Test I think the concept has room for improvement.

IMO the code is hard to read and complex. Not really suited for our users.

------- Brainstorming, how I would tackle the problem

I think calling the widget should look more like this:

<$apexchart chart-type="line" title="Release Sizes" series="DataTiddlerTitle" config="GlobalLineSettings" />

This will give us the possibility to do much more dynamic things. Like show several charts using the list-widget and assigning the names to the parameters dynamically.

<$list filter="[tag[LineChartsData]]" variable="data-tiddler">
  <$apexchart chart-type="line" title={{!!chart-title}} series=<<data-tiddler>> config="GlobalLineSettings" />
</$list>

A tiddler tagged LineChartData would need to have a field: chart-title: Release Sizes and the text would need to be the desired JSON data.

---

If the JSON-data is dynamic as in your example it should be possible to define a "data-config-tiddler" instead of a data-tiddler. The data-config-tiddler can contain a receipt, how to build the JSON series that the library needs. Something similar to this:

yaxis.title.text: KB
series.name: Sizes
data-filter: [tag[ReleaseNotes]!tag[ToDo]has[caption]sortan[]]
data-template: {x:'{{!!caption}}',y:{{!!size}} 

I'm not entirely sure about the data-config-tiddler structure. But I'm only thinking about it for the time needed to write this text.

That's my ideas for now.

What do you think?

[andrewgoz]

I have solved my original question by creating a Story object using new $tw.Story() and passing that (as part of a bound object) to a function that can be called from the click handler. That function calls story.navigateTiddler() using the click event target property to search the DOM for the "from" tiddler.

Regarding the eval() issue, that has been replaced with Function('"use strict";return(text)')() which appears to be the best of the bad options. I understand the issues with eval() and eval()-like code, but given how ApexCharts works by using JS callbacks to implement a lot of important functionality, replacing all the required callbacks with handlers flexible enough to provide replacement functionality seems to me to be a very large project with end-user complexity approaching that of JS callbacks itself. Right now, for me, it's not worth it.

As my wiki is entirely under my control, security issues are not a concern.

As a test, I've got the widget preferentially parsing as JSON, falling back to the Function constructor if that fails. I've also created a JSON version of my test timeline chart, but I consider the result unacceptable without the data label override callback.

For my thoughts on making the widget easier to use, I was wondering if a second widget could be used to generate the ApexCharts options structure for simple charts. Similar to that suggested above, but like:

<$apexchart>
<$apexchart_options type="line" title={{!!chart-title}} series=<<data-tiddler>> />
</$apexchart>

I thought about supporting something like <$apexchart type="line" title={{!!chart-title}} series=<<data-tiddler>> />, but keeping the widgets separate would keep the main widget as simple as possible and allow for other widgets to implement custom chart options generation.