text/html vs html fragments and changing default representation

203 views
Skip to first unread message

Eric Drechsel

unread,
Apr 10, 2012, 5:30:19 PM4/10/12
to tidd...@googlegroups.com
I'm exploring using create [1] to provide unobtrusive/transparent editing for HTML fragment tiddlers. A fragment is naked content, with no chrome (no <html>, <body>, etc) (as an alternative to markdown, wiki markup etc)


Issue 1: I'm not sure what mime type to use. text/html-fragment? application/x-html-fragment?

Issue 2: I'd like to render the fragment using a template that wraps the naked content markup with chrome markup. So if you request content-type: text/html it would use the template do the transform. I haven't written any plugin code for tiddlyweb, but AFAIK this is pretty easy to do on the server side. However, I'd like to be able to provide the template itself as content, using some fairly safe template language like mustache. Is there anything like this in TiddlyWeb already? Is this the right tree, or is there a better way to achieve the same result using the native idiom?

In the short term, I see two alternatives for my use case:
 
1. I could just do all browsing/editing via a single HTML "app" using hash routing:

/create <= the app HTML
/create#myNote <= edit the note.

This approach is the approach other editors are taking, and it's less invasive, but it would requires a more sophisticated client-side (async loading etc).

2. I could host my own TiddlyWeb and change the template on the server side. This would probably be a good way to develop the above functionality.

Eric Drechsel

unread,
Apr 11, 2012, 12:02:00 AM4/11/12
to tidd...@googlegroups.com
To answer my own question, I found the post customizing the html representations on tiddlyspace.com [1] which explains what's currently possible. Unfortunately this doesn't include changing the template for the HTML representation, but I can do what I need by including custom javascript.

chris...@gmail.com

unread,
Apr 11, 2012, 8:12:10 AM4/11/12
to tidd...@googlegroups.com
On Tue, 10 Apr 2012, Eric Drechsel wrote:

> To answer my own question, I found the post *customizing the html
> representations on tiddlyspace.com* [1] which explains what's currently


> possible. Unfortunately this doesn't include changing the template for the
> HTML representation, but I can do what I need by including custom
> javascript.

If you're using TiddlySpace, or a TiddlyWeb where you don't have
access to the server and/or server-side code, the the HtmlJavascript
HtmlCss tools are pretty much the toolkit.

However, if you're running your own TiddlyWeb, there are tons of
options, some of which I'll describe in response to your original
message.

--
Chris Dent http://burningchrome.com/
[...]

chris...@gmail.com

unread,
Apr 11, 2012, 8:46:34 AM4/11/12
to tidd...@googlegroups.com
On Tue, 10 Apr 2012, Eric Drechsel wrote:

> I'm exploring using create [1] to provide unobtrusive/transparent editing
> for HTML fragment tiddlers. A fragment is naked content, with no chrome (no
> <html>, <body>, etc) (as an alternative to markdown, wiki markup etc)
>
> [1] http://createjs.org/

That looks interesting.

In reading over what I've just written it occurs to me that I've
misunderstood what you're trying to do. You're not wanting to access
rendered content, you're wanting to access content that is stored as
HTML. In that case if you set the type field on the tiddler to
text/html, when you ask for it as text/html you'll just get the
text/html, it won't be cooked by the server. For instance:

http://tiddlyweb.tiddlyspace.com/explorer

is a raw HTML tiddler.

Your javascript code could add chrome as needed.

What follows may be useful info, but not entirely germane:

> Issue 1: I'm not sure what mime type to use. text/html-fragment?
> application/x-html-fragment?

How TiddlyWeb sends the HTML of a tiddler depends on the HTML
serialization being used.

The default in plain TiddlyWeb is very simple, generating what you call
a fragment. However, further up the stack, a middleware called
HTMLPresenter wraps it in chrome if the user-agent looks like a
browser. If you're running your own server you've got a few options:

* Disable HTMLPresenter by removing it from server_response_filters
* Augment HTMLPresenter so it behaves differently, based on someting
in the environment.
* Subclass the HTML serialization to _not_ set tiddlyweb.title in the
environ (this is used to trigger HTMLPresenter) when the mime-type
is something of your own design.
* Instead of asking for HTML, ask for JSON, and provide the render
flag, compare the following:

http://cdent.tiddlyspace.com/HelloThere.json?render=1;fat=0
http://cdent.tiddlyspace.com/HelloThere.json?render=1;fat=1
http://cdent.tiddlyspace.com/HelloThere.json?render=0;fat=1
http://cdent.tiddlyspace.com/HelloThere.json?render=0;fat=0
http://cdent.tiddlyspace.com/HelloThere.json

In TiddlySpace, HTMLPresenter is not used, instead HTML is output via
a subclass of the HTML serialization that uses Jinja2 templates to
provide the chrome. Therefore the first two options above are no good,
but the 3rd (assuming you're running your own server) and 4th are.

> Issue 2: I'd like to render the fragment using a template that wraps the
> naked content markup with chrome markup. So if you request content-type:
> text/html it would use the template do the transform. I haven't written any
> plugin code for tiddlyweb, but AFAIK this is pretty easy to do on the
> server side. However, I'd like to be able to provide the template itself as
> content, using some fairly safe template language like mustache. Is there
> anything like this in TiddlyWeb already? Is this the right tree, or is
> there a better way to achieve the same result using the native idiom?

There's a plugin called tiddlywebplugins.templates that provides the
infrastructure for using Jinja2 templates with TiddlyWeb.
TiddlySpace's HTML serialization uses that. Jon (at least I think it
was Jon) did some work that allowed templates to be kept in tiddlers.
Ben has done work with client side mustache templates.

> 1. I could just do all browsing/editing via a single HTML "app" using hash
> routing:
>
> /create <= the app HTML
> /create#myNote <= edit the note.
>
> This approach is the approach other editors are taking, and it's less
> invasive, but it would requires a more sophisticated client-side (async
> loading etc).

There's a lot of this sort of thing happening on TiddlySpace these
days, including my own editor at http://edit.tiddlyspace.com/

Reply all
Reply to author
Forward
0 new messages