[TW5] is ther a way to restrict where a macro is called from?

85 views
Skip to first unread message

myst...@gmail.com

unread,
Oct 3, 2017, 8:05:09 AM10/3/17
to TiddlyWiki
Ideally, i would like to create a macro, but i want it to only be called from my approved places in the wiki.
Is there a way to check either the caller or the macro's place in the rendered hierarchy, such that i can limit its behavior based on that?

Jed Carty

unread,
Oct 3, 2017, 8:14:13 AM10/3/17
to TiddlyWiki
You can check the currentTiddler against an approved list of places, but anything you make can be modified by other people. If you make javascript macros than you can make it harder to get around but there isn't any way to prevent someone who knows a bit about what they are doing from getting around it.

Mark S.

unread,
Oct 3, 2017, 9:43:44 AM10/3/17
to TiddlyWiki
Depending on your use case, you might be able to use the ImportVariablesWidget to re-use macros only when you want them.

Mark

myst...@gmail.com

unread,
Oct 3, 2017, 5:51:25 PM10/3/17
to TiddlyWiki
Thanks for the responses. I decided to go with the currentTiddler method, and since this macro is in javascript,
some poking around in the tiddlywiki source shows that i can reference this.getvariable("currentTiddler") from inside the macro.

While i can't make this method secure against a determined and knowledgeable person,
I'm opting for the 'locks only keep the honest people out' approach.

PMario

unread,
Oct 4, 2017, 5:23:48 AM10/4/17
to TiddlyWiki
On Tuesday, October 3, 2017 at 11:51:25 PM UTC+2, myst...@gmail.com wrote:
Thanks for the responses. I decided to go with the currentTiddler method, and since this macro is in javascript,
some poking around in the tiddlywiki source shows that i can reference this.getvariable("currentTiddler") from inside the macro.

TLDR;

IMO you should describe the functionality, that you want to have a bit closer. ... I think you want to use an approach that begs for trouble.

----------------- Reasoning ---------------------

Your described approach is very error prone and even you or your users (for sure) will break it by accident.

lets say:

tiddlerOK ... is a tiddler where the macro is ok
tiddlerNok ... macro should not run

Now consider this:

tiddlerNok  contains your macro for testing and you call it like this:

tiddlerOK  contains the following code:

{{tiddlerNok}}    <-- your macro may work

and

{{||tiddlerNok}}  <-- macro fails since currentTiddler is still set to tiddlerOK


The same may happen if you use the <$list> widget with the variable parameter set to eg: variable="listItem". ... Inside the widget scope currentTiddler isn't set. ... if the variable assignment is missing currentTiddler will be set.

Constructions described above are all over the places. .. So I think it will cause you quite some headache. .. If not immediately it may cause very hard to find problems in the future.

just some thoughts!
mario

Reply all
Reply to author
Forward
0 new messages