Change physical order of fields in a tiddler

#1

If you use the following in a tiddler;

{{{ [all[current]fields[]] }}}

Without sorting it presumably presents the field in the order they are stored within the tiddler.

If we wanted to manage the order these fields are listed, such in a form we could develop a field-list and/or use a sortby filter and values however this involves some work and added complexity.

My Question is. Can anyone conceive of a way of modifying the “tiddler store” for an individual tiddler or a set of tiddlers to reorder the physical order of the fields such the separate ordering is not necessary?

If for an example a template tiddler had the fields physically ordered, then this field order could be made to apply to all tiddlers created from it. In some cases a user may wish to reorder the fields in an individual tiddler.

#2

Hi @TW_Tones this will sound discouraging, but at present the ordering of tiddler fields is technically dependent on the browser’s implementation of JavaScript. It would be a rather major rewrite of the tiddler store to change that. The change would have far reaching consequences. For example, it would also require us to change the JSON format used for tiddler storage and interchange, and to change the HTTP API.

2 Likes
#3

Yeah, as @jeremyruston merely hinted at, js object property storage is a tricky thing to navigate. It’s improved somewhat over time, but legacy code needs careful consideration (if you’re thinking like me, “best avoided”, you’d be doing yourself a favor).

1 Like
#4

Thanks Gentlemen,

Based on your comments I will then resort to a fields-list not unlike a list field, to allow the odering of fields.

I suppose the next question is does such a facility remain bespoke or could we embed this the standard release so we all use a shared compatible method?

There seems to be a need for global and local fields-lists so perhaps it is best implemented in a variable or transclusion (which does not need the wikify widget, or can hide its use).

#5

Actually, all is not lost. Mostly, you can rely on the ordering but only if you’re the sole creator and maintainer of the objects – though I think you’ll find it hard to find a spec that voices that so clearly – for obvious reasons, they want to “cover their asses”. IOW, if there’s no third-party stuff entering the code domain, and you’re the only creator of objects, then maybe you can rely on the order.

Spec wise, I don’t recall reading that implementers need worry about order of property storage and retrieval (but it’s been years since I read anything from tc39, so that isn’t worth much). But…

Out there (in the real world), I have code that relies on the ordering but under some pretty unique circumstances: I am in sole control of the objects’ creation. With hundreds of thousands of users, for over a decade, I still worry about it failing “one day”, just because of something I forgot to take care of. So I still I won’t say it’s “safe and reliable”.

Like I said, Tones, “best avoided”.

1 Like
#6

Lets avoid depending in physical order and establish a logical order mechanisium.

1 Like
#7

The fields-widget https://tiddlywiki.com/#FieldsWidget has an include parameter, that can be used to sort the output, similar to sortBy. The sort parameter needs to be set to no

The problem is the same as sortBy has, You have to know the field-names upfront. So it’s impossible for a plugin author to predefine the list, because s/he doesn’t know which names the user wants to use.

#8

Unless that is what the plugin does for the user?

I am now thinking we may be able to use a cascade of filters that looks for a definitive sort order, which the designer or user can override.