Tiddlywiki5: Proposal: Make use of url to influence the boot (starting) of TiddlyWiki

[felixhayashi]

I think using URL get parameters to influence how the wiki starts would be a big plus for TiddlyWiki in general.

Status quo

At the moment, the TiddlyWiki may be already partly influenced using the URL: The user can include in the link which tiddlers to open.

Suggestion

edit GET parameters should not be used, but something else e.g. how angular does it (GET notation but behind hashtag).

Add a URL parsing module (see "implementation" below) and a set of rules (get parameters) that influence the wiki. For example:

• search=hello
  
  
  
  • prepopulates the search field with hello world
  
  
• view=storyviewXY
  
  
  
  • Starts the wiki in storyviewXY
  
  
• theme=tight
  
  
  
  • Starts the wiki in theme "tight".
  
  
• tab=recent
  
  
  
  • Opens the recent tab at beginning
  
  
• …

URL looks like: http://tiddlywiki.com#?search=hello&theme=tight

Possibilities are endless and the benefit is big. For example you can now store a bookmark with different start modes of your wiki. Or you can send a link to your wiki to a friend with certain setup that opens your wiki in a certain predefined way: Imagine: How cool would it be if you sent somebody a link that starts your wiki using a presentation theme?

Implementation

I looked at several light weight apis for URL parsing/manipulation and I would suggest to include: https://github.com/Mikhus/jsurl. I will use it in the next TiddlyMap release as a module already.

Proof of concept

In the next release of TiddlyMap, I will include an option to influence how TiddlyMap starts when the page is loaded in the browser (https://github.com/felixhayashi/TW5-TiddlyMap/issues/130).

This way, a user will be able to send somebody a link e.g. …

http://mywiki.tiddlyspot.com?tmap-enlarged=fullscreen&tmap-view=myview123

…and it will start in fullscreen showing the view (map) myview123

• Quick demo: https://github.com/felixhayashi/TW5-TiddlyMap/issues/130#issuecomment-169867952

-Felix

[tobibeer]

very much like the idea

[twMat]

+1
This is a very big matter and, in deed, endless possibilities.

[pmario]

TiddlyWiki already has some built in url handling tools. ... So why include a dependency instead of improving the existing api?

[felixhayashi]

@pmario could you point me to the section of th TW source code? thanks. In general, the url handling mechanism would need to support everything (not more or less) that https://github.com/Mikhus/jsurl also does, so unless our TW url handling code is already fairly advanced, this looks pretty much like investing man power (programming + testing) in something that exists already and is MIT.

[sukima]

Doesn't SafeMode do just this? It pre-processes the URL on boot to adjust boot behavior? Maybe it is worth starting there?

[twMat]

Doesn't SafeMode do just this? It pre-processes the URL on boot to adjust boot behavior?

Yes, and I believe actually @inmysocks is using this very idea for the TWederation work. Hope you guys can make it to tomorrows hangout (nr 96) and you can ask him to explain.

[felixhayashi]

Hi @sukima, @twMat

GET params are part of the HTTP protocol: https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_GET

It does not make sense to deviate from that standard in order to pass url variables. TW adds some limited custom url instructions on the basis of hashtags but I would not follow this path when it comes to passing url parameters – it's highly anti standard.

[tobibeer]

It does not make sense to deviate from that standard in order to pass url variables.
TW adds some limited custom url instructions on the basis of hashtags but I would not follow this path when it comes to passing url parameters – it's highly anti standard.

Let's just say, for readabilities sake that's how it's been implemented for titles, I imagine. As for all the complex parameters, possibly including permaview and startup filters, etc... I agree that get params appear a much simpler, let alone standard way of both defining as well as making use of parameters.

[felixhayashi]

Let's just say, for readabilities sake that's how it's been implemented for titles, I imagine.

that must have been the reason, I guess…

As for all the complex parameters, possibly including permaview and startup filters, etc... I agree that get params appear a much simpler, let alone standard way of both defining as well as making use of parameters.

Excatly my understanding.

[sukima]

The main difference between the query string and the hash tag is this:

• With hashes that information is not sent to a server and it meant to be local to the page. I'm a little shaky if this also means it is not pat of the browser history.
• With query strings these are part of the URL and unique and is sent to the server.

[felixhayashi]

With hashes that information is not sent to a server and it meant to be local to the page. I'm a little shaky if this also means it is not pat of the browser history.

Nothing is send to the server unless you make a form submission. form submissions (non ajax) that reload the page do not make sense in a one-page app like tw anyway.

But if you are concerned about that, the boot process could delete all GET params once it has loaded from the url.

When looking at angular, it hides "GET params" behind the hashtag but in case of TW this would cause collisions with the existing hashtag notation for tiddler titles.

[sukima]

@felixhayashi I have to disagree and this is now more semantics then a point. If your wiki is at http://example.com/tw.html then if you add query parameters (http://example.com/tw.html?foo=bar) then the server will receive the following when you press Enter to load the page:

GET /tw.html?foo=bar HTTP/1.1

Where the hash tag of http://example.com/tw.html#foo:bar the server will receive the following when you press Enter to load the page:

GET /tw.html HTTP/1.1

So per the spec query params are part of the URL while hashes are browser only.

[Jermolene]

@sukima is quite right, I think. The location hash portion of the URL is for the user agent to use as it wishes; the query string portion is for the server to use as it wishes.

The query string is visible to JS code in the browser, and so code can be written to read it and react to it, but we can't ever include that functionality by default in the core; other people need to be able to integrate TW into their own server architectures, which might have their own requirements for the query string. For example, @zooko's LAFS work and the recent work we've seen on http://zeronet.io and the (personal blog hosted on it)[http://bit.no.com:43110/1G9s2eptrshvMmXaR1egEnGcbL9WdeQFAa] both involve a URL architecture that we can't change; we can co-exist by being strict about the concerns of the client the server.

As I say, none of this rules out a plugin that parses the query string and does stuff, my concern here is about the proposed change to the core.

As discussed in Hangout no. 96, I'd like to start closing issues that have proved inactionable, and I think this one meets that criteria.

[felixhayashi]

@sukima fair argumentation, I forgot about the user hitting enter. So I agree GET parameters should not be used, but something else e.g. how angular does it (GET notation but behind hashtag).

As discussed in Hangout no. 96, I'd like to start closing issues that have proved inactionable, and I think this one meets that criteria.

Hi @Jermolene

ehm, maybe the discussion became sidetracked or the OP title was misleading, but the real proposal here is not to use GET url params but to use portions in the url to influence the wiki startup (which would need to happen in the core). I think this idea is extremely powerful (see OP). I changed the title and the description, would you mind reconsidering it?

-Felix

[sukima]

@felixhayashi,

use portions in the url to influence the wiki startup (which would need to happen in the core). I think this idea is extremely powerful.

Perfect opportunity for a Pull Request. With the code there would be more to discuss and be _actionable_.

[felixhayashi]

Hi @sukima,

Perfect opportunity for a Pull Request. With the code there would be more to discuss and be actionable.

why would there be more to discuss with the code? I mean is not even clear whether @Jermolene likes the basic idea. Unlike other issues, this issue is rather technical and there is not much to show in a demo – also I provided a proof of concept in the OP on the basis of TiddlyMap. I would not want to write code if it is not even clear how the syntax of the url parameter notation should look like…

[danielo515]

It's a pitty that this great idea is frozen.

@felixhayashi , have you solved the mentioned issues in your implementation in TMap?
I see that you have closed your issue:

https://github.com/felixhayashi/TW5-TiddlyMap/issues/130#issuecomment-169867952

I want to add that I thought about this feature for NoteSelf too. It's quite curious that I ended thinking about the same thing even without reading this issue first. Looks like it is something that more than one project could benefit from. When an idea is good it just arises in more than one mind 👅

In my case, it could be useful to select the local database to load, so you can point a link to a certain notebook.

Regards

[Jermolene]

@danielo515 there is nothing to prevent you from writing a startup module in a plugin that extracts data from the URL query parameters.

[danielo515]

Hello @Jermolene,

It allows me to change the behavior of my startup modules, which is great. But the original request was to influence the BOOT sequence, which is slightly different. Unless I misunderstood @felixhayashi intentions.

[Jermolene]

Hi @danielo515 the OP is suggesting adding the parameter parsing technique to the core. I've already explained why I don't think it's appropriate for the core to use the mechanism. But there's nothing to stop plugins such as TiddlyMap or yours from using the technique.

[inmysocks]

I did use this idea successfully and will probably revisit it for twederation. I am not sure where my working experiments from this are but I can look around later and see if I can find my work from before if you want to see how I did it. From what I remember it was pretty easy to set up.

[bsapwindows]

I used TiddlyWiki about 10 minutes and I want this functionality as well. It's been almost two years, is this implemented in some other way? Excuse me if it's been implemented, because I can only find this one issue on Google.

[Jermolene]

Hi @bsapwindows I've not seen anyone experimenting with anything like this but it remains fairly straightforward for anyone who wants to have a go.

[linonetwo]

So how to do such a search now? I'd like to create an Alfred or Zazu plugin to search my tiddlywiki's content, and I need something like

http://mywiki.com#?search=hello

or even

http://mywiki.com#?search=[all[tag[hello]]

So I can get my tiddler efficiently.

Just like I'm searching github using

https://github.com/search?utf8=%E2%9C%93&ref=simplesearch&q=

In my Zazu plugin.

[Jermolene]

Hi @linonetwo try:

https://tiddlywiki.com/#:[tag[HelloThere]]

[sukima]

OMG! that is amazing?! How have I not realized #: is a thing?! That is amazing! Thank you! _{best day ever}

[linonetwo]

Yeah, after knowing this, I can use regex search https://groups.google.com/forum/#!topic/tiddlywiki/2TCK1reiZl4 to search tiddler whose title contains a string

---

update:

Oh, seems regex search is built-in now. I can just 127.0.0.1:xxx/#:[regexp[\d+$]] to perform search for tiddler ends with number.

This example is taken from @kookma 's Title has only digits

[kookma]

Hi @linonetwo
You may also like to see this

http://tw-regexp.tiddlyspot.com/