\define test()
Paragraph 1
Paragraph 2
\end
<<test>>
\field my-field
Paragraph 1
Paragraph 2
\end
{{!!my-field}}
action-listops
... gets NO new functions in the first runThis sounds interesting can you please clarify. Are you saying, Such "field" definitions would make the content in the field pragma become a value of this "Virtual Field".
If I use edit-text I can name such fields and edit them as if they were independent fields but I would only be editing part of the text field where this definition resides?
- If my above understanding is correct perhaps it would be misleading to call them fields, although they will behave as such.
- Perhaps they could be considered "sections" that are addressable like fields.
- Will they be able to be made global, or defined in a tiddler tagged view template?
- Can we then display them conditionally?
If this interpretation that they are like sections is correct then it could allow code modularisation within a Tiddler, such that sections of code are defined at the top and included below in a structured form.
\field my-field <-- Definition
Paragraph 1
Paragraph 2
\end
{{!!my-field}} <-- Usage
\field a1()
Multi Line text
Some more text
\end
| Cell | 1 | 2 |
| a | {{!!a1}} | {{!!a2}} |
Thanks for your innovative thinking
Could you share a few sentences of the workflow we would use with the field pragma?
A possibly wrong example
Either manualy, as a result of a view template tag or in the text field of a template tiddler, place the field pragma in the text to name the field and provide its default content. On saving such a tiddler the field definitions will create actual tiddler fields in the current tiddler and those fields will now be available using standard text references to the fields.
Thanks
Tony
\field my-fieldParagraph 1Paragraph 2\end
--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a184c225-0dc6-46b9-9d7e-45d35b32943e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
If I understand the proposal correctly, the idea is that one could type multiline fields into the main textarea of a tiddler with the following syntax:\field my-fieldParagraph 1Paragraph 2\end
Then, when the user saves the tiddler, the content of the textarea is parsed, the field value(s) extracted and saved into the tiddler in the usual way. I’m assuming that the field pragma wouldn’t be replicated in the text field as well as the specified field?
title: test-tiddler
tags: a b c d
my-field: @@@my-field
\field my-field(type:binary)
0
\end
Conversely, when initiating editing a tiddler, multiline fields are prepended to the text of the tiddler and placed in the textarea.
If I’ve got that right, my first thought is that the idea of a process to convert a tiddler back and forth to a single textarea representation is interesting, and doesn’t present any particular issues if it’s just a UI thing.
Re-using the pragma syntax is confusing because this “parsing” is nothing to do with the main wikitext parser; perhaps it would be clearer to use an extended .tid file syntax.
This is a nice idea. It also seems related to an "Advanced Edit Mode" I described here: https://github.com/Jermolene/TiddlyWiki5/issues/3308
Hey y'all, RK from the discord.
If I want to display the text of a user field (say, user-defined-field) and format it I have to then workaround by somehow editing Tiddler1 's user-defined-field while also making sure to avoid using $edit-text in a manner that would cause the re-rendering issue.
For a user that wants to build a UI that's a complete headache. There's a lot to be said for the ability to have a multi-line field that is directly attached to the tiddler itself and not as a sub-tiddler
- User defined fields, when made multi-line would not impact core
- We already have the capability to embed multi-line fields into a tiddler, we just have to use a workaround
- list filters would become less complex when displaying multiple pieces of data linked to a single tiddler provided the user wishes to have multiple formatted fields
I am also of the opinion that organizationally multi-line fields are easier to manage. I know it's a personal preference or opinion but sometimes I have trouble navigating particularly long list fields because the data I want to manipulate, change or reorganize might be over 100 characters in. Some list fields when manually reorganizing can become cumbersome, and this would help alleviate some of that as well.
In an ideal world I would love if a multi-line-field indicator was just a checkbox next to the indicated field in edit mode. Then, we can default all field editing to single line fields unless the user specifies otherwise. There's a ton of untapped design space therein that can prevent the need for "hacky" workarounds like users trying to over-utilize subtiddlers or creating custom UIs.
Perhaps a related hack
In an experiment in the past I noted I could build a slightly modified .tid exporter such that the tiddler text to export contained field value pairs as in the raw tiddler syntax.
Fieldname: field value (from memory)
once this exported tiddlier was reimported these fields became standard tiddler fields. It provided a mechanisium for user edits of text to be turned into field value pairs.
My thought is this method could be used along with your suggestion without the export/import step. Such field value pairs could be used in template tiddlers to create and populate fields and even restore default values if the fields are deleted. Of course also introducing multiline fields.
\fields
Fieldname: field value
Fieldname2: field value
Multilinetextfieldname:
text on next line indicates multi-
line field handled as you suggest
\end
The above would populate fields with default values if they do not exist, including the multiline text fields defined in the tiddlers text body.
Just a hack idea
Regards
Tony
-- At the moment if you want to maintain a dataset organised by Movie Title that includes rich content, including line-breaks, its over complicated. You have to have several Tiddlers per Movie as soon as you include lines breaks. A simple example is ACTORS. Say you have 35 actors in a movie. Is that 35 fields? 35 Actor Tiddlers? Or better 1 field with 35 lines?
-- A "Movie" is a good example of a referenced object that is a whole. It does not need to be spread over multiple Tiddlers. Currently for richer data you have to (over)break it down.
-- One might argue a solution here is to emulate a relational database via JSON structures. But actually, I think complex (tree-nested) JSON is unnecessarily complex for the specific USE CASE.
-- The Use Case Supposition (with good reason) is one-movie is one-thing. A movie is one object... Even IF George Clooney appears in 13 other movies, when I'm looking at the record for one movie I could still link to Clooney but I think over-spawning "actor-tiddlers" would pretty soon ruin a TW's utility in over-complexity.
Jeremy: Re-using the pragma syntax is confusing because this “parsing” is nothing to do with the main wikitext parser...
But I'm slightly uncomfortable with using the text field as a surrogate field-holder. It seems counter-intuitive?
The confusion for me, I think, is Tiddlers Have Fields Already so why are we adding others a different way rather than changing field behaviour?
title: tiddler-title
tags: a b c [[d e]]
my-field: 1 line of text is possible
text field starts here. Fields can't handle muliti-lines.
\field my-tags(type:tag)
a b [[c d]]
\end
I do think there is a difference between field structure and field manipulation and in that sense I, perhaps naively, find the approach slightly confusing (BUT do like the ultimate aim :-)
! Title
Movie Title - bla bla ..
! Description
Short info about the movie.
!! Actors
* Actore A
* Actore B
* ...
! Details
Other stuff, that may be interesting.
tony
my-field: this has<br>two lines
my-field: this has
: two lines