[TW5]How to use canonical uri field to point to local files

[Danielo Rodríguez]

Hello,

Now I see that the canonical uri field can be used to point to external files that got rendered into the TW tiddler body, I want to point to some source code files.

But, I am not getting any success. The way I'm doing it is using relative paths

_canonical_uri: ../../Dropbox/somewhere/file.js

I am using node.js version, maybe that is the problem? Should I use the standalone edition instead?

I  have to say that I find the name of the field hard to type. I remember a pull request to add a drop-down with common fields, was it merged?

Regards.

[Jeremy Ruston]

Hi Danielo

Now I see that the canonical uri field can be used to point to external files that got rendered into the TW tiddler body, I want to point to some source code files.

But, I am not getting any success. The way I'm doing it is using relative paths

_canonical_uri: ../../Dropbox/somewhere/file.js

I am using node.js version, maybe that is the problem? Should I use the standalone edition instead?

If a relative URI is provided, then it will be taken as relative to the URI of the TiddlyWiki HTML file. Presumably in your case that's http://127.0.0.1/index.html, in which case the given relative URL won't work.

To get this arrangement working we'd need to get the core serving static files, as discussed here:

https://github.com/Jermolene/TiddlyWiki5/issues/1148

I  have to say that I find the name of the field hard to type. I remember a pull request to add a drop-down with common fields, was it merged?

Yes, see the attached illustration.

Best wishes

Jeremy.

​

 

Regards.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/535e465a-dd0f-4163-a541-3fdc4cbdcec4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jeremy Ruston
mailto:jeremy...@gmail.com

[Danielo Rodríguez]

Hello Jeremy,
Thank you very much.

Very interesting github issue. Is possible to add arbitrary routes to the server module?

[Jeremy Ruston]

Hi Danielo

Very interesting github issue. Is possible to add arbitrary routes to the server module?

At the moment it can only be done by hacking the code of server.js. The ticket is a proposal to introduce an extensible mechanism.

Best wishes

Jeremy.

 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c52b9975-da93-42a4-a7ad-c0db5674a392%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Danielo Rodríguez]

Hello,

I'm trying it with the HTML single file edition, and it is not working neither. 

I put a URI field pointing to a relative path, but the file (wich is a shell script) is not being rendered as a tiddler. I also set the tiddler field to plain text, and it is not working

[Jeremy Ruston]

Hi Danielo

If you're working off a file URI then the xmlhttprequest will only work on Firefox; Chrome raises a security exception.

Do you see any error messages in the developer console or network activity?

Best wishes

Jeremy.

[Danielo Rodríguez]

Hello Jeremy

I'm using Firefox, and I don't see anything on the console.

Both the wiki and the file are on the local file-system. The canonical uri has the following format:

../../../programacion/something/algo.sh

Thanks for your prompt answer

[Danielo Rodríguez]

Hello Again,

Chrome is not raising any error neither, only for the favicon. If that helps

[Mark S.]

Is _canonical_uri supposed to work with text files? I can't get it to show a simple text file with either an absolute address (provided by tiddlysnip) nor a relative address. But it does work with absolute and relative addresses of image files.

What I mean is that the text of the text file does not show up in the _canonical_uri tiddler. I tried saving the text file in the 4 different file encodings offered by Notepad.

It wouldn't even show me a text file in the same directory as the TW file.

I could get it to work with an absolute, but not relative path to a PDF (with application/tiddler).

It's odd that advanced file formats work but not a simple text file.

Mark

TW 5.1.8, FF 33.0, Win 7

[Jeremy Ruston]

Hi Mark

On Thu, Sep 10, 2015 at 5:04 PM, 'Mark S.' via TiddlyWiki <tiddl...@googlegroups.com> wrote:

Is _canonical_uri supposed to work with text files? I can't get it to show a simple text file with either an absolute address (provided by tiddlysnip) nor a relative address. But it does work with absolute and relative addresses of image files.

What I mean is that the text of the text file does not show up in the _canonical_uri tiddler. I tried saving the text file in the 4 different file encodings offered by Notepad.

It wouldn't even show me a text file in the same directory as the TW file.

I could get it to work with an absolute, but not relative path to a PDF (with application/tiddler).

It's odd that advanced file formats work but not a simple text file.

What browser and operating system are you using?

The _canonical_uri field is handled very differently for images vs. text. For images, we just assign the URL to an <img> element, and there are no cross-domain issues. For text tiddlers, the equivalent approach would be to use an iframe. However, if we did that we wouldn't be able to access the actual text of the tiddler. So, instead we use xmlhttprequest, a JavaScript API provided by browsers since the dawn of time. The trouble with it is that browsers have implemented a number of restrictions on its use in the interests of security. Worse, those restrictions differ between browsers.

One situation where external text tiddlers work consistently across browsers is when the TiddlyWiki HTML file is accessed over HTTP (or HTTPS) and the tiddler is on the same server (technically, on the same domain). Everybody should be able to see the full text of Alice in Wonderland here, even though it is a lazily loaded external tiddler:

http://tiddlywiki.com/prerelease/index.html#Alice%20in%20Wonderland

However, setting the _canonical_uri to a different server will only work if that server is "CORS enabled".

The situation is not so good if the HTML file is being accessed on a file:// URI. In my tests, Chrome refuses to load the external tiddler, while Firefox is quite happy.

The complexity of the implementation landscape is why I initially resisted adding this feature. As I feared, it's proving hard for many users to get it working because of the requirement to understand the browser limitations.

Best wishes

Jeremy.

 

Mark

TW 5.1.8, FF 33.0, Win 7


On Wednesday, September 9, 2015 at 8:17:47 AM UTC-7, Danielo Rodríguez wrote:

Hello,

Now I see that the canonical uri field can be used to point to external files that got rendered into the TW tiddler body, I want to point to some source code files.

But, I am not getting any success. The way I'm doing it is using relative paths

_canonical_uri: ../../Dropbox/somewhere/file.js

I am using node.js version, maybe that is the problem? Should I use the standalone edition instead?

I  have to say that I find the name of the field hard to type. I remember a pull request to add a drop-down with common fields, was it merged?

Regards.

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/6db8a709-91e1-4ca8-90ec-8c170d78a15f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Danielo Rodríguez]

Hello Jeremy,

El viernes, 11 de septiembre de 2015, 11:30:24 (UTC+2), Jeremy Ruston escribió:

while Firefox is quite happy.

The complexity of the implementation landscape is why I initially resisted adding this feature. As I feared, it's proving hard for many users to get it working because of the requirement to understand the browser limitations.

I do understand browser limitations, and I am getting the expected error on chrome, so far so good. But, I am not able to make it work on firefox. Which version of Firefox are you using? I don't get any error, but I don't see anything on the console neither, nor in the network tab.

[Jeremy Ruston]

I'm using Firefox 40.0.3, which I think is the latest version.

Maybe try downloading the content of tw.com from github, and see if you can open "Alice in Wonderland" in /prereleases/index.html in Firefox:

https://github.com/Jermolene/jermolene.github.io/archive/master.zip

Best wishes

Jeremy

[Mark S.]

Hi Jeremy,

In case it wasn't clear, I was talking about reading local text files. I wouldn't think there would have to be any security restrictions against reading local files -- I can use the browser to browse to and read local text files.

Firefox 33, TW 5.1.8, Win 7

Thanks!
Mark

[Jeremy Ruston]

Hi Mark

In case it wasn't clear, I was talking about reading local text files. I wouldn't think there would have to be any security restrictions against reading local files -- I can use the browser to browse to and read local text files.

You'd be surprised. As I said in my message above, Chrome doesn't allow code running from a file:// URI to perform local file access. Also, accessing file:// URIs is off limits in all browsers from http:// URIs.

So, what browser(s) and operating system are you using? Can you share the paths you're using too?

Best wishes

Jeremy.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/e0e4755c-3199-4800-b2c1-f0743006fc88%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Mark S.]

Hello Jeremy,

Paths tried (all from LOCAL - not http://) directory:

  temp.txt (same dir as TW)
  ./temp.txt (same dir as TW)
  file:///g:/data/TW2014/temp.txt (same dir as TW)
  ../Business/papers/2015/test.txt (relative path to current TW)
  file:///g:/data/Business/papers/2015/test.txt (absolute path)

All with text/plain. However, text/html does work. So maybe text/plain isn't supposed to work with canonical URI?

I am using FIREFOX 33 with  WINDOWS 7 and TW 5.1.8

Thanks!
Mark

[Jeremy Ruston]

Hi Mark

I am using FIREFOX 33 with  WINDOWS 7 and TW 5.1.8

Ah, that's the problem - the external text feature is new in 5.1.10. You can try it out at the usual prerelease address.

Best wishes

Jeremy.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/b9b6c84b-8088-438b-8dc7-52b583d3d110%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Danielo Rodríguez]

You're right! using the text/html type works flawesly!!

Jeremy, in 5.1.10 is it supposed to work with text/plain? I'm testing and it does not work neither. I'm trying to display a bash file as plain text. 

[Jeremy Ruston]

Hi Danielo

You're right! using the text/html type works flawesly!!

text/html has been implemented for quite a long time, but it's implemented differently: as an iframe. That means that the content appears visually part of the wiki, but isn't properly integrated with it.

Jeremy, in 5.1.10 is it supposed to work with text/plain? I'm testing and it does not work neither. I'm trying to display a bash file as plain text. 

In the current prerelease it works with tiddlers with the type text/vnd.tiddlywiki and a _canonical_uri field pointing to a .tid file. Accessing such a tiddler triggers the retrieval of the file. The .tid file can specify a different content type than the "skinny" version. So you could use the mechanism to retrieve plain text tiddlers, but as things stand the plain text file would need to be a .tid file. (I'll look at extending the mechanism to read other file types).

Have a look at the "Alice in Wonderland" sample that's included in the prerelease. Serving that scenario from an HTTP URI is the only thing that works straightforwardly, without the kind of wrinkles we're discussing in this thread.

Basically, the current support for external (wiki)text tiddlers only straightforwardly answers one use case: being able to publish a TiddlyWiki HTML file over HTTP that offloads some content into external files that are only loaded on demand. There's a lot of other things that can be done with the new support, but care needs to be taken to understand the implications of the limitations that browsers impose.

Best wishes

Jeremy.

 

[Danielo Rodríguez]

Hello Jeremy,

I can understand this limitation on the fileSystem adaptor: it has to figure it out what to do with the files based on it's extension and turn them into tiddlers. But, in this scenario we already have the tiddler, and the tiddler has a type defined, so it should be straightforward to find a correct parser to process the external content.

Regards

[Tobias Beer]

Perhaps an alternative way...

Embedding A Text File @ tb5

Best wishes,

— tb

[Danielo Rodríguez]

Hello Tobias,

Thank you for your approach, I'll check it out