Extending the type field for user types?

Developers
#1

Folks - I ask this question here because it needs a developers eye over it.

Background
The tiddler “type” field contains what are effectively, mime types, as I understand it. Some types will use a different way to “render” the text field eg text/plain and text/css that is they render the text field differently to the default. I understand this may also relate to deserialisers. In these cases the body text is not rendered.

Recent community activity

  • A number of people have being asking how to programaticaly hide-body or fold mechanisms to stop simply rendering the the text (default type text/vnd.tiddlywiki)
  • With edit in tiddler now possible people are reconsidering building forms or alternate views for different tiddler types.

My personal projects
Since I am building solutions that introduce a tiddler type “object-type” field to describe a tiddler,

  • I also want to hide the standard rendering of the text field
  • Provide a custom view template for each type
  • Provide a custom edit template for each type
  • Provide a templating mechaisium for each type
  • Introduce so new innovative types of tiddler which treat the text field quite differently.
  • One type could be print ready

But we already have something similar the type field.
I have being researching how to hack this type mechaisium and wonder it it would be possible to permit new types of the form user/subtypename for example;

  • user/contact for a contact record, template form and view template
  • user/location for places
  • user/subnet for an ip subnet.

The advantages of this approach is

  • we need not bloat the view template to take account of different ways to display alternative tiddler types
  • We maintain a single type field and reuse an existing mechaisium
  • Each type can include its own macros, css and other logic or content independently form other types.
  • transcluding a different type can inherit its tiddler “type” allowing us to transclude multiple tiddler types into one tiddler and have its formatting honored. For example;
Content

{{Tiddler}}
<hr>
{{||Tiddler}}

more content

try the above where “Tiddler” is set to text/plain, it is transcluded as expected with no additional logic required. Thus one tiddler can have multiple tiddler types transcluded in it.

Notes;

  • Although this would introduce new types they may very well be based on existing types, most commonly text/vnd.tiddlywiki but also text/plain to name a few.

Questions;

  • So how plausible is this?
  • If not have you an idea how to achieve this otherwise?
  • What difficulties can you foresee?
  • Could this one day be in the core, even if it were a plugin to start?

[Edited - postscript]

  • One could choose to have a desktop/tablet/mobile tiddler for the same content if they needed a different structure.

Thanks in advance, Tony

Definition: Pure Tiddler and Impure Tiddler
#2

This is a problem right now! and having possibility to custom view/edit a tiddler is very useful!
So, a mechanism like what you proposed is helpful!

1 Like
#3

Thanks for the support mohammad. We need some feedback from people with some deeper core knowledge.

Althought I will contine tobresearch it.

#4

While I think that hacking the type field to do this is not the way to go, I have considered it. We need to have that field clear to drive data/file-type logic. But, I think we can totally use something similar/parallel to implement a custom viewtemplate mechanism.

#5

In the context of the wider Internet architecture MIME types convey how information is formatted within a byte stream. They are not intended to convey application level information such as the meaning or interpretation of that information. The internet uses text/plain but not text/recipe, text/tv-schedule etc. MIME types are the concern of low level transport, and typically not of applications.

In TiddlyWiki, we use MIME types in the same spirit, and in particular we use them to choose which parser should be used to process a tiddler. So it makes sense to introduce new MIME types if one needs to modify the parsing process, but otherwise it’s not so useful.

For the purpose you describe, I typically use a field called “role” to convey the application-level purpose of a component tiddler.

#6

Jeremy,

I understand where you are comming from. I use object-type st present. If using a user\type interfears too much that is fine. I want however to have a similar mechanisium available. Such that tiddlers with such a type can even be given their own viewtemplate and perhaps not include global macros or the default body rendering. Of course it would fall back to these if not present. A simple tweek would be to hide the body but others would be treating the tidder differently including the view, edit and editor toolbars.

The view template method is in effect a cumulative thing and most often starts with multiple conditional display tests and only changes the body. I would like a user type to go a few steps back to allow customisation.

Example may inclued a more robust readonly tiddlers, form tiddlers that respond to a type and import its own macros and vatiables or very large toddlers of data that include data query and edit tools wìth out triggering refresh.

Here i am not talking about touching the page template. That is what the layouts are for. I want someting to provide the same hackability to the tiddler view template.

I know we can set alternate view template but i am keen to see this respond to different types before it is invoked. This we could have tiddlers that are prsented in fundimentaly different ways.

I belive some custom tiiddlers like this could be highly performant as they need only invoke what they need not the overhead a generic tiddler has, such as global variables and macros.

I have a dozen or more design ideas that this will facilitate. I wont “bore you with them here”.

#7

When you are talking about extending in the type field, are you thinking about how it works vs other field inputs? Because it is different way how we can introduce the values in the field: input vs selector. For example, you can hide the body of a tiddler creating the field hide-body with yes as value.

The second point is about how many changes we can introduce which will be useful for the most of the users. The hackabily of TW lets create custom solutions for individual cases.

I think the needed changes would be in the viewtemplate and in the edittemplate. And surely they are refer to filters

#8

Alvaro

I am well versed in the use of view templates and I am trying to address limitations I have come up against. Such hackability I propose would be invisible to most users. However solutions could be developed without needing to edit core distribution tiddlers.

The current view template facility ìs realy just altering or adding to the display of the body. Try changing the type of a tiddler and you will see how even the editor toolbar buttons can change in responce.

Try using dump variables in the view template and you will see how much is included within the view template mechanisium. I am suggesting this may not be needed for custom tiddler types that may need only a small subset.

The ability to contol more than just the body text on tiddlers including using alternate view and edit toolbars, even a different editor view altogether is what i am looking for.

The closest thing to what I am asking for is the current type mechanisium hence my suggestion to extend that mechanisium.

#9

I grok what Tones is talking about. In my JsonMangler plugin, I coded a custom $csv display widget and figured out how to hide the normal body & display the widget when a tiddler’s type is set to “application/csv” (not normally found as a Type in TW).

#10

csv has MIME type but it isn’t includen in TW like many others.

But the simple tweek for include a template, for example, for display contact from an agenda, I think that, breaks the design and I think that add extra noise in the dropdown of field type. And how many ways are there to save a contact?

I think that is better play with templates (with a new system tag) and we can add a field widget like the used in type ($:/core/ui/EditTemplate/type) for an extra field for this templates then we only need modify the filter in the body tiddler. Then we can also add some “config” for a template for a specific tag.

#11

I continue to research this and draw the following;

  • The type field invokes a different parser and editor
  • Most non-binary types are treated as text and thus use the wiki parser
  • user types can be created eg user/form and this will invoke an editor with a “custom toolbar” on tiddlers with that type.
  • So any text wikitext is treated the same

Current Editor types are only bitmap and text
If you create a new one and set the edit type to form a tiddler so formed returns; Undefined widget ‘edit-form’

  • edit-text widget would notmaly be used
  • or edit-bitmap

So an alternate would need a widget for edit-form

  • Cloaning and editing $:/core/modules/widgets/edit-text.js to $:/core/modules/widgets/edit-form.js empowers the edit-form
  • At this point there is no difference with the form type and ts display
  • The standard view template appears on it.
#12

it is becoming clear that given the view and edit templates are set in $:/core/ui/PageTemplate/story set before the story is instantiated we need to use modified versions of $:/core/ui/ViewTemplate and $:/core/ui/EditTemplate

The above view and edit tiddlers can be cloned and named in the respective $:/config/ui/ViewTemplate and $:/config/ui/EditTemplate tiddlers, lets call these the “reformed tiddlers”.

In each of the reformed tiddlers we address one tiddler at a time, so here we can redirect tiddlers with an alternate “user type” field to a different set of view and edit templates.

As a result, and because other changes would be too complex, I think it best to abandon using the type field and adopt another field such as object-type or tiddler-type with new view and edit templates testing for these and redirecting to another “template” if it exists.

#13

If we build other full view and edit templates, we may reuse existing template tiddlers so tagged, as a result we would use other tags, however this will result in needing to add the tag to the template tiddlers and thus edit the core tiddlers. Alternatively we could clone each of these, creating quite a few possibly identical tiddlers.

Instead I am looking for another mechanisum, perhaps not tags but a list field, or filter. The current filter is; [all[shadows+tiddlers]tag[$:/tags/ViewTemplate]!has[draft.of]] and remains valid for all tiddlers without an object-type (and then some)

#14

Please let me rephrase the Question;

Is there any harm my utilising the type field to include user/name types which will make use of alternate edit and view templates?

#15

Yes. As mentioned by Jeremy, it’s used for MIME types, so this may have unforeseen effects in browsers depending on how it is used.

In practice it may enable you to do some things for now in TW. Proceed at your own risk.

#16

As long as it is for personal use, feel free to experiment.

I would strongly advise against doing so in code meant to be shared with the community, as it would set a poor precedent and potentially cause headaches for users down the road if such code was widely used.

Consider any such usage subject to potentially breaking in future core versions even if it works well now, and backwards compatibility not being something you can rely on, since it is intentionally going against the recommended purpose of the field in question.

#17

So let me restate;

FYI: text/vnd.tiddlywiki is alread a custom type!