I see merit in both approaches, however at the risk of opening a tiddler slices vs fields argument, semantically I have an issue with the slice approach.
To me the word text in terms of a tiddler means content of that tiddler. In the case of a plugin, the text is the content of that plugin - the javascript - the source code. In the case of an image, I would therefore expect the content of that tiddler to be the data representing that image. A data uri, as in the example contains the mime-type, so the type field seems a bit redundant as a result (as you can extract it from the data). However, what I would like is an easy *quick* way in my plugins to work out whether a tiddler should be treated normally, or specially. I can get the tiddler slice for type in your method, however I'm concerned that if I had a several megabytes file (leading to extremely long tiddler text), the get tiddler slice method might be slow. Using a field for this, would grant quick access to plugins to this important data, and the fact that it is not editable via standard tiddlywiki could be a good thing - I shouldn't need to change the type if plugins are doing it for me. If you can prove me wrong on this concern, that would be a relief. The url/path fallback also concerns me slightly. By storing data in this way, theoretically I could change the url of the image to point to something else. Then the data in the data section corresponds to something completely different to the url. Likewise I could incorrectly set a type to be image/png when actually the data uri says it is image/jpeg. Doesn't this undermine the data integrity? I however see use in the notes markup - if I have a base64 image or some svg, it would be good to be able to have some text fallback to describe the drawing (which could also be used as an alternative text when either can not be rendered), so that when I click edit without any plugins I have some context to what I am viewing. I've not been very helpful here... sorry :) I'm still on the fence observing the different possibilities. Jon On Jul 1, 10:49 am, "[email protected]" <[email protected]> wrote: > On Jun 25, 2:05 pm, FND <[email protected]> wrote: > > > However, the problem I see here is being tied to the TiddlyWiki > > universe. Your approach - leveraging sections and slices - requires > > parsing of the tiddler body, and thus a certain awareness of its > > structure. This is problematic for a generic system like TiddlyWeb, > > which is designed to be content-agnostic. > > This isn't necessarily that much of a problem. If the content needs to > appear in a particular form in the TiddlyWiki, then the server-side > just needs to make sure that it properly processes to that form when > generating the TiddlyWiki. The storage system can continue to do > whatever it likes. Serializing to a particular form on the server is > not too terribly complicated. > > What becomes complicated is making sure that the TiddlyWiki does the > right form of PUT to save stuff back to the server. That complexity > can be held in the client (where it ought to be for sake of > scalability and tweakability). > > So really, it is a matter, as we've been saying, of agreement on some > format, any format really, that is satisfactory for the various client > side use cases and then documenting it so server-sides can serialize > to it. -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
