Replies: 6 comments 13 replies
-
|
Just a thought: For political correctness we could use "blocklist" and "passlist" instead of black&white |
Beta Was this translation helpful? Give feedback.
-
|
Is that established terminology for what it refers to? |
Beta Was this translation helpful? Give feedback.
-
|
I think we should define what are the properties that make datatiddlers useful and "easy to use". Then we can think about a "replacement that has the same properties" and more.
That are my minimal properties that need to be satisfied. Or they should better be excelled! |
Beta Was this translation helpful? Give feedback.
-
|
Not a must have, but a nice have: Distinct columns for easy reading. The current syntax makes the value column "uneven". |
Beta Was this translation helpful? Give feedback.
-
|
i remember previously reading about this
... managed to find this comment
wrt alternatives i found this mention of 'JSON Pointers to reference data' but tbh idk how that compares to whats curetly posible with data tidlers methods ect .. |
Beta Was this translation helpful? Give feedback.
-
edited: |
Beta Was this translation helpful? Give feedback.
-
|
Second thought - It may be, but we need a better EditTemplate See: How the TW internal data structure looks like and why data-tiddlers are not optimal #6116 |
Beta Was this translation helpful? Give feedback.
-
That is one great writeup! Thank you very much for it. So that post clearly infers that we should use fields. So the question is how this would match your demands listed here above, to make datatiddlers "easy to use". Looking at your demands and thinking how this would work with fields, I'm thinking a conversion needs to take place when opening such a tiddler to edit it and when saving it. Basically, the edit "UI" can look like it does now, all in the text field, but when closing it, this is converted into separate fields. This conversion is likely slow but it is then fast to use the datatiddler. AND there can be a neat viewmode UI showing a table with the field values and editors for the key values, similar to how custom fields are displayed, but here in viewmode. Then you can manually edit values without going into edit mode, i.e without the slow conversion. For your demands:
check
check
check
check (or maybe I don't understand what you mean with "transport settings")
?
To view or edit is just like normal, but the very step in-between might not be. But we could even have a viewmode UI with direct editors to the field values! This makes the datatiddler pretty table! (Possibly even: For the instances where the key value is a tiddler title this could even show as links!)
check
check
check |
Beta Was this translation helpful? Give feedback.
-
Reading and writing data from the store to the UI is no performance problem, because it's always only 1 tiddler that is handled. Problems come up, if we need to read a lot of tiddlers, with "poorly" written filters and nested lists. ... There is a PR in the works, that will help us to create a better UI to edit fields: #6377 With the help of this PR we will be able to not only improve "date handling" but to improve the overall UI for fields. eg: It should be possible to have the same UI for fields as we have for tags now. ... It should be possible to create dynamic multiline editors for fields ... with some new templates. Those templates should also be available in view-mode if done right. .. So the end-result may be a UI that doesn't make a big difference between view and edit mode. ... The new "cascade" filters should have paved the way to those functions. .. |
Beta Was this translation helpful? Give feedback.
-
|
Oooh! #6377 and what you describe gives me goose bumps! OK, so I take it that if #6377 is implemented then my idea here about "converting" text content into fields isn't really relevant then - and the overall problem with data tiddlers will likely be solved. |
Beta Was this translation helpful? Give feedback.
-
|
The big issue is that the data is stored in the text field & this triggers all references in all widgets to update any time any of the json data is updated. This skips over a large part of TW's rendering optimization. Imagine a data tiddler holding 100 "people" objects in an Array. Now open 50 tillders tagged "$:/person", each of which transcludes one of the data objects. Now change person-100's email address. All 50 tiddlers rendered in the story river must be refreshed- even though visually the person changed might not even be displayed. Now it would be REALLY COOL if, on "application/json" & other data tiddlers, that Field References would auto-grab the data (in the text field) at the same index... I imagine calling tiddler.getFieldStrings() on a data tiddker & getting all the data as the "text" key but Also getting keys & values for all data objects in the text field... hrm then we have keyname clashes possible. Or maybe some other way to hook nested json data into the appropriate refresh mechanism. |
Beta Was this translation helpful? Give feedback.
-
|
@joshuafontany If I do open 50 data-tiddlers, I don't have a problem with some refresh-penalty. I expect it. ... IMO the big problem is if it touches the core UI. ... |
Beta Was this translation helpful? Give feedback.
-
don't you think this is a design issue and should be addressed in the core? |
Beta Was this translation helpful? Give feedback.
-
This can only be addressed, if every element in a data-tiddler becomes a tiddler. ... But that's not what we (the users) want. Jeremy refused to merge the functionality that is now the keyvalues plugin, because he doesn't want to add new functions for data-tiddlers to the core. His opinion is, that it was a mistake to implement it in the first place and from a "code complexity" point of view he is right. There is a high chance, that the whole functionality will end up in a plugin and will be removed from the core. IMO the biggest "pro" for data-tiddlers is that users love them. ... So we will need a really good replacement to keep everyone happy. |
Beta Was this translation helpful? Give feedback.
-
Is this still the case in 5.2.0? I know transclusion now only refresh if the field being transcluded has changed rather than the tiddler. I don't recall if the same improvement works for indexes as well. |
Beta Was this translation helpful? Give feedback.
-
|
If you use data-tiddlers as a pure "key-value store" without a connection to the UI, it probably is the best way to deal with "single level" key-values. ... There is no real alternative from my point of view. |
Beta Was this translation helpful? Give feedback.
-
|
There is some discussion going on about typed fields, with which it would be possible to create JSON-like tiddler fields. ... BUT ... In the end such a field would be a mini-tiddler as Jeremy described it in a response in that thread. ... So it's a bit of a "dead end" ... kind of |
Beta Was this translation helpful? Give feedback.
-
|
Subthreads within the bigger thread have a tendency to hide so, as the momentarily bottom-most post, I just want to refer to @pmarios post above where he comments on #6377 . My interpretation is that this will solve the raised issue... which I now note is a Discussion, not an Issue, so it is not closeable. Thank you all. |
Beta Was this translation helpful? Give feedback.
-
@Jermolene has explained that he wishes to replace data tiddlers. Yet they are popular, perhaps mostly because of their ease of use.
I want to see if we can come up with "design ideas" for a good replacement for data tiddlers. Deprecating data tiddlers is thus a presumed starting point in this discussion, so the discussion is not about whether data tiddlers should stay or not, or if they're good or not.
...
One (obvious?) idea might be to use fields to define the key-value pairs.
For this, we'd need a different edit template for this to be practical because it would be slow to feed in one field at a time and click [create field] etc. If the
textfield is still there, it would be possible to keep notes about the dictionary, which would be nice.If individual fields define the key-value pairs, then we'd probably need some mechanism to exclude (black list) specific fields from being treated as such pairs. (I can't recall if there is some kind of "get all indexes" tool (filter op?) but this is a case where this woudl be a concern). Or maybe a white list.
One idea would be to enter a special "edit mode" when editing data tiddlers that converts the fields into one easily editable text field (resembling how they currently look) and when saving the tiddler they are converted back into fields. This might be a backward compatible solution? In addition to the automatic conversion, there could be a button to manually toggle back and forth. This is not super elegant UI/UX but data tiddlers is probably not a daily thing to edit manually so it'd be sufficient IMO.
Another UI idea is to make edit mode custom fields more accessible. Tiddler type "data tiddler" could present the fields as a two column table (think Excel) and one could easily navigate with arrow buttons or maybe tab button. I like this idea. Should make for a very clean UI.
...apropos Excel... could it even allow calculated values depending on other index values? Does this thought even make sense?
|foo|3|
|bar|5|
|sum|foo+bar|
...
A presumption here is that fields indeed would be an acceptible solution. Another idea would be a separate tiddler for each key-value pair. Sounds bloaty to me, but who knows.
Thoughts? Further ideas?
Beta Was this translation helpful? Give feedback.
All reactions