Step 1: Getting a TiddlyWiki to report tiddler info (created and modified dates) to Session Storage. Process triggered by “?action=do_rpt” appended to a TiddlyWiki’s URL.
https://cjveniot.neocities.org/TW_A.html?action=do_rpt
Relevant/necessary tiddlers:
SetSessionStorageItem.js
Post Render Startup Actions
Copy the two tiddlers above into a TiddlyWiki, save, refresh, and add “?action-do_rpt” to the url.
This is a cool trick. With a little JavaScript you can remove the regex based processing of URL and expand it beyond a single action.
Ref: Quick Tip: Get URL Parameters with JavaScript - SitePoint
Aside:
Man, I wish you had started a separate discussion thread (with a link back to this one and a link from this one) related to that for a full discussion “over there” instead of intertwingling that with the intent of the original post.
Because what you bring up is worthy of its own thread.
Mostly: I have a couple of cognitive disabilities, and I get confused and overwhelmed when various threads of discussion are all mixed together branching off in really different ways all on the same web page.)
Not your problem, but if I stop participating in this thread (i.e. not answering questions related to the original post), I hope folk understand why I’m out.
Now, back to Riz’ post:
You are referring to this thing which decides whether or not to enter a process of reporting info about all tiddlers to Session Storage:
<$list filter="[[$:/info/url/search]get[text]regexp[action=do_rpt]]">
Although I cannot stand doing things in javascript, there are two scenarios in which I will use javascript:
Why on earth would I use javascript when I could just have multiple of those lines for various processing?
For example:
`
<$list filter="[[$:/info/url/search]get[text]regexp[action=do_process_A]]">
…
</$list>
<$list filter="[[$:/info/url/search]get[text]regexp[action=do_process_B]]">
…
</$list>
<$list filter="[[$:/info/url/search]get[text]regexp[action=do_process_C]]">
…
</$list>
<$list filter="[[$:/info/url/search]get[text]regexp[action=do_process_D]]">
…
</$list>
`
That seems pretty clear and concise with just TiddlyWiki syntax.
What benefit would we get replacing that simple code with javascript?
Hi cj.v,
Man, I wish you had started a separate discussion thread (with a link back to this one and a link from this one) related to that for a full discussion “over there” instead of intertwingling that with the intent of the original post.
Sorry about that. It was unintentional, I hope you consider that.
What benefit would we get replacing that simple code with javascript?
It was a tangential thought. I assume you are showcasing a single-response API. If we parse the search parameters into a widget and respond to the query in a switch-case tree, the code block could be more manageable, less fragmented. Calling entirely different branches from a single point in a much less verbose way, DRY too.
Again, in contrast to your take on JavaScript - mine goes the other way around. Prefer JS over TW WikiText. More chances of finding a solution in internet if I run into an issue, and the knowledge I acquire during the process will come handy outside the context of TW.
Sincerely,
Riz
Hi cj.v,
Man, I wish you had started a separate discussion thread (with a link back to this one and a link from this one) related to that for a full discussion “over there” instead of intertwingling that with the intent of the original post.
Sorry about that. It was unintentional, I hope you consider that.
Hey, no worries, no need to apologize. I’ve been told before, not in these words: that’s the way forums work, and I should get used to it.
The way forums work usually cognitively sucks for me (I need clear paths/organization), but it is what it is, the forums are what they are.
All I can do is ask for some understanding and forgiveness if an when I get irritated by too many people and too many discussion off-shoots and/or run away from a thread of discussion.
Much appreciated !
What benefit would we get replacing that simple code with javascript?
It was a tangential thought. I assume you are showcasing a single-response API. If we parse the search parameters into a widget and respond to the query in a
switch-casetree, the code block could be more manageable, less fragmented. Calling entirely different branches from a single point in a much less verbose way, DRY too.
I doubt I’m showcasing a single-response APO because I have no idea what that it is. I don’t need to parse any more than one parameter, so list widget is good enough for the job.
The final solution I’m building will involve processing handled by BASIC. Stuff that I’d rather not do in TiddlyWiki syntax.
Again, in contrast to your take on JavaScript - mine goes the other way around. Prefer JS over TW WikiText. More chances of finding a solution in internet if I run into an issue, and the knowledge I acquire during the process will come handy outside the context of TW.
I’m a big believer in not being dogmatic about strict TiddlyWiki syntax for everything. Use what makes most sense, whether it be leveraging what you know well already (because it is quick, more logical, whatever), or veering away from what you know just to learn something new/interesting (even if it isn’t the “best” way and/or just for fun and/or have some time to kill.)
Sincerely,
Riz
Cheers, best regards, rock’n roll !
