Simplest way to make missing tiddlers display:none or visibility:invisible?

#21

No, you would need to hardcode the value of tv-story-list which for the default layout is $:/StoryList.

{{{ [list[$:/StoryList]is[missing]!is[system]nsort[]first[]] }}}

1 Like
#22

Perfect! Now (as @TW_Tones was suggesting) I can actually close those missing tiddlers after setting the fields, and not have to worry so much about keeping them open in order to work with those incoming variables.

1 Like
#23

Note that you can also put the variables in the URL as part of a query string, i.e. after a ? character instead of as part of the permalink.

TiddlyWiki will ignore them, but you can still read them from startup actions.

1 Like
#24

While this thread is open, for potential future development:

How would a filter extract the info from the query part of the url variant being loaded? (I don’t find any obvious documentation on queries / query strings here or at tiddlywiki.com site…)

#25

Visit https://tiddlywiki.com/empty.html?name=ferret&color=purple and then look at the shadow tiddler: $:/info/url/search.

So the startup actions would split/parse the text of this tiddler and extract the information needed and save it in tiddlers for reference.

This is cleaner in the sense that you do not need to deal with missing tiddlers in the story at all.

#26

Excellent, thanks.

The documentation is here: https://tiddlywiki.com/#InfoMechanism

But I didn’t find it with my intuitive search terms (query, permaview, url)… It’s there under “url” – but quite buried under a gazillion tiddlers with a url field.

(So, this request-for-better-documentation is flagged here for the general vague community of people tracking things that could be documented a bit more explicitly!)

#27

That makes me wonder why there isn’t also a $:/info/url/fragment node. Even if it didn’t dynamically update with permalink/permaview actions, it could be very useful to have the initial value (such as #InfoMechanism) available during startup actions.

Does anyone know, was this an oversight, or was it intentional?

#28

Hi @Scott_Sauyet as you note, the problem is that the current info mechanism only handles static information that doesn’t change after the wiki has loaded.

There are some GitHub tickets with further discussion:

#29

Thank you. I read through all those issues, and the concern was exactly the one I expected.

I wonder if there’s a potential middle-ground of creating a tiddler that is removed once the start-up actions have completed. If one of those actions wants to create a more permanent version of the initial state, it’s free to do so, but otherwise, this is just gone. I have no idea if this is done elsewhere in TiddlyWiki now, creating a transient tiddler, but, as an outsider, I can’t see anything fundamentally wrong with the concept.

One nice point is that with the two equally familiar names of fragment and hash, we could do this with one of them, and reserve the other for potential future use without worrying about backward compatibility – although of course near-aliases have their own problems.

#30

I am not sure that there is an obvious, clean way to remove the tiddler at the end of startup, but I’d be more concerned that it would be confusing for users.

I think the best way forward is to extend the info mechanism to support dynamically changing values, along with a mechanism for triggering action strings when an info value changes.

#31

Jeremy, perhaps the context isn’t entirely clear (on this long thread) – in this kind of case, the tiddlers are designed to be invisible, and so nothing would “disappear” from users’ point of view. Removing them from the story river (after using them to set various field-values) would save a bit of anxiety over whether these distracting but missing and non-displaying titles are visible in the Open tab (for example) or in other plugins that reference the story river (such as quickjump).

I do think the “query” approach is more semantic. Alas, I’ve already built a whole approach (which needs to work at least through the rest of this semester) around user-specific permaviews. Because it’s served up within an iframe users don’t see their individual url values, and I don’t want to encourage users to poke around with easily reconstructing others’ “cookie” values (they’re serving the function of keeping some student info in view, while keeping other student info away from easy discovery).

So, my solution for now involves having calculated permaviews whose hashes hold id/key variables (to determine the content of an iframe, where that url is never seen by the intended LMS visitors). In other words, these users ideally never interact with or even see mention of the titles of the missing tiddlers which are serving this back-end purpose.

#32

Apologies @Springer, my comment to @Scott_Sauyet was referring to an implementation detail about the proposal for adding access to the URL fragment identifier via a $:/info/... tiddler. @Scott_Sauyet had proposed that one of those info tiddlers would disappear after startup.

1 Like
#33

As I said, this was an attempt at a middle ground. It could also just be labeled:

    $:/info/startup/url/fragment

to make it more clear that it’s temporary.

But this would be better.

… Much better.

… Much, much better.

Of course this is me speaking of as a developer who’s used to being able to easily listen to arbitrary events.

Even so, there’s likely some value in keeping the initially loaded fragment available, so that we could offer an equivalent to a “Home” button that returns to the initial state.

#34

@Scott_Sauyet I am not exactly sure why but on this subject an example that comes to mind is $:/temp/volatile/ mentioned in RefreshThrottling or using a namespace. This thread has helped me clarify in my mind a little more on handling different namespaces.

In brief, a startup action can take steps to store whatever it wants from whatever information is available such as the $:/info tiddlers, and store it how it wants.

  • Arguably if all information is stored on the URI that simply saving this should be enough to craft a link to reload with the same URI, you called this “Home”
  • Storing something the startup actions determines in tiddlers and fields of tiddlers, be they temporary, volatile or permanent (if save is possible) the designer can decide what to call them and use a namespace or naming convention.

Namespaces
We can simply adopt a namespace for whatever we want either inside the system name space $:/new or outside #:/new the detail is of course how different parts of tiddlywiki then handle the tiddlers with a given namespace. Areas we may want to alter are;

  • Do they appear on standard searches, use $:/ to stop this already
  • Do they appear in common lists eg: recent/open
  • How are they displayed in the story - now we have the cascades to handle this aspect for view, body, title etc…

In relation to this Topic for example we could develop a namespace for tiddlers that are not visible in the story or standard lists.

In reality there are not many places we need to intervene in TiddlyWiki to get a whole namespace to be developed with different qualities. That is tiddlers with an alternate namespace to be treated differently to others. Existing examples include system/non-system/shadow/temp/state/$:/info etc…

  • intervening can be done in a numbers of ways including override existing core tiddlers and macros, clone and use a modified version, hide the current tiddler eg remove the side bar tag, and replace with another that has the same caption etc…
  • In short modifying some filters to exclude or include given prefixes via a subfilter is going to be sufficient in most cases.

I raise this because not only can we do this quite easily but I foresee being able to make such namespace design a hackable feature of a particular tiddlywiki edition, or perhaps sometime in the future part of the core.

  • It may be as simple as replacing existing filters with filters that are obtained from a config tiddler or global macro. For which we can modify.
  • Adding filter operators to support a new namespace such as in the is or all filter operators would be nice.
  • The question then is what different behaviours may we want from different namespaces? in addition to “not displayed in lists and story” in this Original topic.
What's the standard way to not writing Title
Lets discuss new and or custom namespaces
#35

Yes, while $:/temp/volatile is meant for a different purpose than what I suggested here, they are clearly related concepts.

The trouble is that the information is not available right now through the info mechanism (or, as far as I can tell, through any other mechanism unless you write custom JS.) If you visit

https://tiddlywiki.com/#RefreshThrottling

and look at $:/info/url/full, you will find that the fragment identifier is not included. The value will just be “https://tiddlywiki.com/”.

You can contrast this with a url that includes a query. If you visit this:

https://tiddlywiki.com/?RefreshThrottling (note that this has a ? instead of a #)

then $:/info/url/full has the value “https://tiddlywiki.com/?RefreshThrottling” and $:/info/url/search has “?RefreshThrottling”.

There’s no equivalent for the fragment/hash. Currently, you’d have to descend into JavaScript to get access to it. That’s simple enough JS, but I was suggesting that even though TW hijacks the standard browser fragment navigation, we might still want to know the initial value from page load.

In any case, this suggestion was a work-around, avoiding doing some of the harder work that would make this more robust. @jeremyruston seems inclined to do that harder work, so I think this suggestion is moot.

As to your more general point about namespaces, I’m surprised to hear that it would be relatively simple to add new ones. I would have expected that it would be a fair bit of work, that the current public/system/shadow trio was likely embedded deeply in the code. But I haven’t looked into it and have no basis for that assumption.

If you’re right, and that could become a hackable mechanism, it’s interesting, and I could imagine that one day I might want it, but I can’t think of anything I’ve done so far that really would have benefitted from it. I’d be interested to hear more specifics about how you might see this being used.

#36

Yes, I had not noticed that until you pointed it out. You could say $:/info/url/full returns a lie, it is not “full”.

  • Any reason why not pass the parameters via the “search” ? and not using the # (sorry if I missed a prior answer of yours)
    • Warning: I have seen the ? clash with Timimi saving
  • But yes it would help if the # values were available in the full uri and/or its own “list”

I POSTED in a new thread on namespaces Lets discuss new and or custom namespaces

Lets discuss new and or custom namespaces
#37

Sure. But the current rationale for this is fairly clear. Tiddlywiki appropriates the usual hash navigation in the browser to load tiddlers into the story river. So the initial hash value has limited usage. But there are some possible uses, and it might be especially relevant at load time, or, as I mentioned before, as an alternative “home” link.

Two reasons I can think of:

  • The query/search parameters are meant for the server-side, whereas the fragment/hash one is meant for the client-side. Mixing them up is crossing the streams. They provoke very different behaviors in the browser. Changing the query parameters by default will call back to the server for what could theoretically be entirely different content. Changing the fragment does not refresh the page, although the client side can do what it likes in that case.

  • Using the fragment should work well with the Permalink/Permaview mechanisms, which give you a shareable URL using the fragment.

#38
  • I think that “stream has being crossed” when using Single File Wikis, the wiki is the content and the server in a sense.
  • Well yes, use fragments to reference tiddler permalinks and permaviews.
  • However use the search parameters to pass parameters to change other behaviours which lead you to Posting this topic.

Did you see my reference to https://namespaces.tiddlyhost.com/ ?, which does;

make missing tiddlers display:none or visibility: invisible?

In a systematic way. Althgough perhaps not so simply, it is packaged namespaces.json (26.0 KB) modifies some core tiddlers.

  • But of course you can cause the wiki to “refresh the page” from inside your wiki if you wish.
    • This is only a disadvantage if it takes too long, a big wiki, but almost irrelevant if readonly and cached.
  • Thus the fragments and search parameters can be reissued in a sense.
#39

Partially, but not fully, I think. The various backends for a TiddlyWiki could easily use the query parameters to do specific differentiation in the content supplied. They cannot use the fragment, which is not sent back to the server (or at least didn’t used to be) but is reserved for the client. Reserving the query for the client mostly prohibits such differentiation.

Here’s one possibility: @Springer is using TiddlyWiki in the classroom, using a shared wiki for a class. She may have difficulty adding private commentary to students’ work… because this is a shared wiki, and should probably stay that way. And she’d better not put grades or other more private information into the wiki without possibly running afoul of the law. But what if we could offer her a back-end which allows for both this shared uri:

http://myschool.example.com/philosophy/ethic101/2023-spring/

, which contains only the shared information, but also this

http://myschool.example.com/philosophy/ethic101/2023-spring/?student=123456

, which includes all the common information as well as the more private information.

To log into the latter you have to have the password matching that student id, as recognized by the school.

This should be a relatively straightforward extension to the Node back end or a simple alternative to it. The thing is, if we coopt the search string for the client side, then this is no longer really possible, because perhaps ?student=123456 means something entirely different in the client. I understand that there are alternative ways for the server to differentiate and validate users; the trouble is that this is a tool meant for that, and claiming it for the client removes to capability to do that on the server.

The fragment, meanwhile, is designed explicitly to identify a portion of the document/wiki. While it’s traditionally been used to match an HTML id in the document, TW’s use of it to mark and/or load some subset of the tiddlers is still within the spirit of its design.

I did and have been reading it, although so far I have nothing to add. I’m really hoping to see some more specific practical applications of the ideas, as I haven’t yet figured out how this might be useful.

#40

As mentioned previously, I agree it would be helpful if the fragment(s) or tiddlernames given in the URI could be accessed on the server and in the single file wiki.

  • Or here there could be a private encryption key rather than a password, used to decrypt the students private information for use only in the browser memory.
  • See encrypted tiddlers.

It can already satisfy the following; but of course this discussion has moved on from there.

For example, try it, tiddlers with the _ prefix, follow this link, the tiddler exists but cannot be seen anywhere without work, https://namespaces.tiddlyhost.com/#_Semi-Secret%20content (or paste in a browser)

  • On the namespaces wiki the edit recent and edit recent sidebar tabs do not recognise these exceptions, so you can edit the _Semi-Secret content tiddler

I agree there is value in using a server implementation for some backend details or secrets, but I would urge you to keep an open mind, and I always maintain a single file tiddlywiki perspective, I am not sure your statements about the difference between front end and back end, all hold true. But perhaps this is not the place to discuss this.

For example yet another approach

Encrypted tiddlers

I have in the past used the tiddler encryption plugin to hide a users profile and secret, one could pass the user name in the URI and then use an encryption key to expose the secret.

  • It is also possible to encrypt the whole wiki
  • The current encryption plugin does not have all the features we need but could be “forked” to do so.

But we are again straying from the OT.