Object ID - is it possible?

[twMat]

Would it be possible to apply an ID to macros and even (some? all?) widgets so to target them?

Does the question make sense? What I want is to be able to, for example:

Use this ID to refer to the output of the macro/widget as a unit, so that it can be e.g transcluded? (If that were possible, we could transclude "slices" of tiddlers).

If the ID is accessible as a variable within the scope of the macro/widget, then the qualify macro could be made more easy to use by having it concatenate the ID to its output so to differentiate between multiple instances within the same tiddler. (Currently, the user has to explicitly call qualify with an argument) One use case would to much simplify the popular "slider/accordion" construct as outlined in #5839

[pmario]

Would it be possible to apply an ID to macros and even (some? all?) widgets so to target them?

Yes, but it would be random and so users wouldn't know them. So how should they target them?

Does the question make sense? What I want is to be able to, for example:

With the next sentence ... yes.

Use this ID to refer to the output of the macro/widget as a unit, so that it can be e.g transcluded? (If that were possible, we could transclude "slices" of tiddlers).

The problem is: To access "rendered" elements form a tiddler you have to render the complete tiddler first. The "widget-tree" which is the pre-stage of the html output, is not cached. So everytime the "calling" tiddler is refreshed, all the "referenced" tiddlers would need to be rendered, even if they are not visible. ... So this can make the whole process slow.

That's the main reason, why this function was removed from TW5. TWclassic still has this function.

If the ID is accessible as a variable within the scope of the macro/widget, then the qualify macro could be made more easy to use by having it concatenate the ID to its output so to differentiate between multiple instances within the same tiddler. (Currently, the user has to explicitly call qualify with an argument)

That's not right. ... eg: If the $text-widget will get a known ID=textWidget the qualify macro would create the same value, for every $text-widget in 1 tiddler. ... We need something that is unique inside the widget-tree. Which is more complicated, but doable. ...

The problem here is that it can't be exposed to the users, since it will change, if you add a new paragraph to the transcluded tiddler text. So the widget-ID is way to dynamic to use it by humans.

[twMat]

Thanks @pmario !

The problem here is that it can't be exposed to the users, since it will change, if you add a new paragraph to the transcluded tiddler text. So the widget-ID is way to dynamic to use it by humans.

Hm, my idea is a user set ID that is combined with the "qualify hash" of the current tiddler. The ID is set by the user on a per widget or per macro basis, according to need, like so: <$widget id=foo> and/or as a macro param \define macro(id:"foo"). Thus the ID would be random but also simple to recreate (compare with <<qualify foo>>).

But one point is to save users from manually targeting things because as long as they are targetable then we can have widgets and macros that do this. The $accordion idea is an example - the user would set the ID for the widget instance (e.g <$accordion .... id=3>) and the result would be targetable without the user having to know the full behind-the-scenes ID.

The problem is: To access "rendered" elements form a tiddler you have to render the complete tiddler first. The "widget-tree" which is the pre-stage of the html output, is not cached. So everytime the "calling" tiddler is refreshed, all the "referenced" tiddlers would need to be rendered, even if they are not visible. ... So this can make the whole process slow.

That's the main reason, why this function was removed from TW5. TWclassic still has this function.

(How slow was this feature actually? In total, TWclassic is faster...) It is comforting to hear that the idea at least isn't totally out in the woods. But then, as I outline above, it would be used on a need basis by the user, not for every instance of widgets/macros. It would only be used IF there the user explicitly defines the id=xxx because this is an optional attribute/param.

Problems with my reasoning?

[twMat]

OH, I now see you following posts which seem to touch this!

[pmario]

The problem here is that it can't be exposed to the users, since it will change, if you add a new paragraph to the transcluded tiddler text. So the widget-ID is way to dynamic to use it by humans.

Hm, my idea is a user set ID that is combined with the "qualify hash" of the current tiddler. The ID is set by the user on a per widget or per macro basis, according to need, like so: <$widget id=foo> and/or as a macro param \define macro(id:"foo"). Thus the ID would be random but also simple to recreate (compare with <<qualify foo>>).

OK. Then I did misunderstand your intent here. ... This should work, in a way that I did show with the h1 widget

But one point is to save users from manually targeting things because as long as they are targetable then we can have widgets and macros that do this. The $accordion idea is an example - the user would set the ID for the widget instance (e.g <$accordion .... id=3>) and the result would be targetable without the user having to know the full behind-the-scenes ID.

OK

The problem is: To access "rendered" elements form a tiddler you have to render the complete tiddler first. The "widget-tree" which is the pre-stage of the html output, is not cached. So everytime the "calling" tiddler is refreshed, all the "referenced" tiddlers would need to be rendered, even if they are not visible. ... So this can make the whole process slow.
That's the main reason, why this function was removed from TW5. TWclassic still has this function.

(How slow was this feature actually?

I don't know. It has been a problem, when TW development started. ... but in the meantime we included so many caches, that I can't say how big the performance penalty is today. ...

In total, TWclassic is faster...)

hmmm, IMO not really. It also depends on the number of tiddlers and the 3rd party plugins that are included. Especially the feT-plugin (for each tiddler) had the possibility to slow down TWc quite a bit. ... feT is our $list-widget and filters now. ...

It is comforting to hear that the idea at least isn't totally out in the woods.

Oh, I do miss it quite a bit! ... With TWc you "intrinsically" create a "reusable" structure just by using headings. Headings are a natural way to create structure while you write.

In TWc you can say: <<tiddler [[test##heading 1]]>> and it will show the text between the heading and the next heading ... BUT it has a renaming-problem, if the heading text changes. ...

But then, as I outline above, it would be used on a need basis by the user, not for every instance of widgets/macros. It would only be used IF there the user explicitly defines the id=xxx because this is an optional attribute/param.

As I wrote, it would be possible to search the widget tree of a tiddler, for a marker and include it into the current tree, which technically is a transclusion.

Problems with my reasoning?

No

[pmario]

The only practical way I can see is, that the author defines the "reference-ID" eg:

!.idMario heading 1

If you copy paste the above wikitext into https://tiddlywiki.com/prerelease/ and select widget tree as preview type you will get this.

[
    {
        "type": "element",
        "tag": "h1",
        "attributes": {
            "class": {
                "type": "string",
                "value": "idMario"
            }
        },
        "children": [
            {
                "type": "text",
                "text": "heading 1"
            }
        ]
    }
]

html-output looks like this:

<h1 class="idMario">heading 1</h1>

As you can see, it isn't an id that is assigned, it's a class="idMario" ... BUT this info is can be found in the widget-tree and it is unique enough, if I give a new class-name to every section I want to find later. ... I could also use the html-tag and the text to find the widget but that wouldn't work if I change the heading text later in the process. ... So all references will be broken.

Which also means I'm not allowed to ever change the class-name. ... So as you see, we do have the same problem as we have with tiddler-links.

So having this wikitext

!.idMario heading 1

some text

!.idMarioX heading 1

would allow me to find idMario and idMarioX and also the text between idMario and idMarioX with the right definitions.

BUT I assume that's more complicated as you want it to be. right?

[pmario]

.... BUT I do think with the new JSON store we would have a chance, to create "field-based" tiddler content. that would look like this:

title: test
h-1: ! This is a heading h1
h-1.1: !! This is a subheading 
h-2: ! This is an other heading h1
t-1: This is some text p1
t-2: This is some text p1

{{!!h-1}}

{{!!h-1.1}}

{{!!t-1}}

{{!!h-2}}

{{!!t-2}}

With this configuration every element of the tiddler will be accessible eg: {{test!!t1}} and so on. ... It will only need a new EditTemplate that will handle the creation of the fields and the text in a user-friendly way.

[pmario]

I'm just thinking this a bit further. ... With a "streams-like" outliner, which can handle different wikitext-types the tiddler would look like this:

title: test
h-1: ! This is a heading h1
h-1.1: !! This is a subheading 
h-2: ! This is an other heading h1
p-1: This is some text p1
p-2: This is some text p2
list: h-1 h-1.1 p-1 h-2 p-2

<$list filter="[all[current]list[]]" variable=field>

<$transclude field=<<field>> mode=block/>

</$list>

The funny thing now is, that the list does contain the wikitext elements + the whole info how to build the tiddler content.

So no rendering will be required to extract every singe element we want from the tiddler. It will also be possible to extract several elements. The following example will

<$list filter="[[test]get[list]search-replace:gi:regexp[(^h-1.*p-1)(.*)],[$1]enlist-input[]]" variable=field>

<$transclude field=<<field>> tiddler=test mode=block />

</$list>

The zip file contains the "test" tiddler test-field-access.zip to play with.

[twMat]

edit:
Just after posting I'm wondering if I misunderstood your previous post, i.e:

title: test
h-1: ! This is a heading h1

I interpreted this to mean "inline-fields", i.e inside the text field... but you probably mean separate fields.

Or would the new JSON store somehow enable "inline fields"? That would be fantastic...

/edit

---

@pmario - you bring up so much cool stuff I don't even know where to start. I think they are a kind of "parallel" case to what I'm after - let me explain:

An underlying reason for my OP to brings up widgets and macros is because...:

1. they are ubiquitous in wikitext, we use them all the time
2. their encapsulation of content is "intrinsic"; there is no extra adding of e.g start and end markers.
3. the rendered output is typically "distinct" (e.g ListWidget --> a list, EditTextWidget --> a little editor, etc) so it is likely that the user will want to control these

I'm curious to see if your cool ideas are "parallel" to this or if they can even make my idea redundant.

Your styling ideas where an applied class is findable in the widget tree is interesting. Maybe even more general than my idea above because widgets sometimes have a class attribute. So does this mean we could e.g transclude the output from a widget that has an encapsulating class? If we can both use the class to style and transclude it, it could be very powerful.

The "inline fields" idea is also super cool (and reminds me of #5468 ). How could they be made to work for multi line/paragraph?
Maybe using the same technique you showed with idMario and idMarioX, i.e to have them serve as start and end markers... but this is of course a totally different technique than the direct "inline field" transclusion you outline...

Crazy thought: What if such "inline fields" could allow applying styles just like with !.idMario? Something like so:

myfield1:.mystyle1 Here's some text

One limitation here is that the field marker is not necessarily there when one wants to do the targeting. So one might have to do post-editing to enable targeting a specific text slice.

Tying back to the OP, could somehow widgets and macros have a built in applying of an "inline field" marker? Again the user would need to add some kind of identifier. For example <$widget id=foo/> would be equivalent to the field widget-foo:<$widget/>

Maybe all wikitext could have built in potential to be a field!? ... so ! could be expressed as !: to both signify it's a headline and a field for easy transclusion or other targeting? ... it would be a problem in that there must only be one field named !... so if we reverse it, i.e take "inline fields" and apply the basic wikitext commands directly to them... any field prefixed with ! would also style it like a h1, and any field prefixed * is a li etc. So really just the : character next to it is what makes it targetable...

...how about this syntax then <$widget:foo .... /> i.e the : signifies that the whole widget is a targetable field, with the identity foo!

...

Yeah... I'm in the middle of a crossfire between my two brain hemispheres ra-ta-ta-ta..

[pmario]

edit:
Just after posting I'm wondering if I misunderstood your previous post, i.e:

title: test
h-1: ! This is a heading h1

I interpreted this to mean "inline-fields", i.e inside the text field... but you probably mean separate fields.

Yea, there was a bit of a misunderstanding.

This was just a .tid notation. So you know what fields I'm talking about. .. The I decided to add the ZIP with the examples, which should make it easier

Or would the new JSON store somehow enable "inline fields"? That would be fantastic...

No. ... I did start a discussion "How could system-fields look like with 5.2.x" #5805 ... Which is completely in fantasy land. But it discusses multiline-fields in .tid files. It also would solve some long standing problems .. but there will be much more time till we get something like this.

[pmario]

I think #5850 (reply in thread) is interesting to follow. .. With a new EditTemplate it should be possible to create tiddlers as described in the comment. If the editor is done right the UX should be similar to "streams". ... Where you can use indentation to create an outline structure. .. But it would work with fields instead of single tiddlers.

With a simple ViewTemplate as shown in the comment "text" field, it would be possible build the tiddler text out of fields. ...

The advantage would be, that every field is already simple to access with the current transclusion syntax like: {{title!!fieldName}} ... The second example shows how "ranges" of elements can be transcluded into other tiddlers, using a regexp filter. .. This filter creation would need it's own UI, to abstract the complexity away.

But this mechanism would pretty much do what you want in a performant way, because no pre-rendering of transcluded content would be needed.

So imo we should definitely experiment with that concept. ...

Since the new JSON-store will loosen the rules for field-names it should be easier to create a stream-like structure with field-names instead of tiddler-titles. ...

So I think most elements are already available.

[twMat]

Thanks for following up. What do you want to call this "field approach" of yours? In the following, I will just call it the "field approach":

The field approach
This is very interesting but how can it be made so the user authors his text like this? Streams is (only?) made for "bullet lists" so it is naturally split up into units. But when we type wikitext, this is not as typical. Take for example HelloThere - how do you envision one would create this tiddler but so that its "parts" are in separate fields? (

...and what is a "part"? Actually, I can answer what a part is: It is whatever the user decides and there are often natural "clues" for what should define it, like one part can be a widget, another might be a bullet list, another might be three sequential paragraphs of text, etc. Pretty much like how one "feels" what should be a tiddler. - So how can the user

...so we need a UI that allows smooth creation of fields. Clicking "enter" to create the field and load a new empty one does not work since clicking enter is how to create a new line.

Further, as noted in the OP (even if we've obviously deviated from the OP now) is that widgets and macros intrinsically encapsulate their content. The user doesn't have to do anything extra to define it is a distinct "part", so this is why I wanted them to be targetable. With a "field approach" can we somehow let the user just type wikitext like normal and have the system automatically identify when to cut off for the next field? The author should to the greatest extent possible be able to keep his mind on "Once upon a time there was a ..." and ideally not be interrupted by systemic TW matters.

Many years ago I made (SuperTiddlers)[http://supertheme.tiddlyspot.com/#About%20SuperTiddlers] but it never reached publishing maturity. (As you see in the link, SuperTiddlers were part of a theme but just focus on the SuperTiddlers part if you look at it). So, a SuperTiddler is a kind of compound tiddler that transcludes from multiple other tiddlers both in view mode and the editors in edit mode. It doesn't fulfil the "Once upon a time" vision but it does provide a UI of some sort.

Do you have any thoughts on UI and UX?

[pmario]

Further, as noted in the OP (even if we've obviously deviated from the OP now) is that widgets and macros intrinsically encapsulate their content.

Not really. ... The user decided, what needs to be "blocked". See the HelloThere example. If you want the first 3 paragraphs to be 1 block you can do so. ... If you decide they should be 3 blocks later in the process -- that's fine. ... The same is true for a paragraph and a bullet-list, which technically may look like this

some text, some text, some text, some text, 

<<list-links "[tag[HelloThere]]">>

[pmario]

With a "field approach" can we somehow let the user just type wikitext like normal and have the system automatically identify when to cut off for the next field? The author should to the greatest extent possible be able to keep his mind on "Once upon a time there was a ..." and ideally not be interrupted by systemic TW matters.

Sure that's easy. Just create a tiddler as you do now. ... No fields involved. .. So 1 tiddler is like the whole cake. You can create it as 1 block and eat it as 1 block. ... BUT if you want to share it, you need to slice it. .. you can't have both.

[pmario]

Many years ago I made (SuperTiddlers)[http://supertheme.tiddlyspot.com/#About%20SuperTiddlers] but it never reached publishing maturity.

Very nice and ambitious ...

[pmario]

Do you have any thoughts on UI and UX?

For the beginning I would start simple. The only "block-type" that can be selected is "wikitext". With a slightly different visual styling than a stream block, so it can be recognized as something different.

[twMat]

... "stream tiddler" ... "stream-type" field
IMO we could change that into eg: h1, h2, p, ul, ol, li, quote ... and so on. If this type is changed, it will change the field-name in my setting.

Aha! How about this: Default is p (or div?) but the system detects (i.e reads) the first word or characters and if it matches a predefined type, then this field type is set! E.g if the first row says !!foo bar the field type is set to h2, and if it is [img[ then e.g some style is applied. Etc.

Maybe if the segment ends with some terminating string or char it resets to p for next segment and if there is no termination then it repeats the previous for the next. This way it would be simple to make e.g a bullet list or some other repetitive presentation.

can he keep his mind on "Once upon a time there was a ..." and not be interrupted by systemic TW matters.

Sure that's easy. Just create a tiddler as you do now. ... No fields involved. .. So 1 tiddler is like the whole cake. You can create it as 1 block and eat it as 1 block. ... BUT if you want to share it, you need to slice it. .. you can't have both.

(Maybe there could be a systemic "post split text into fields" via some magic save tiddler button.)

[twMat]

I am still interested in your other approach, i.e:

Class as identifier

In some sense this is closer to the original OP, i.e:

!.idMario heading 1

some text

!.idMarioX heading 1

would allow me to find idMario and idMarioX and also the text between idMario and idMarioX with the right definitions.

But how? Do we have tools for this at all?

When I look at the widget tree it appears as if also widgets and macros can be targeted with this technique, and that they indeed could be made individually identifiable with some user set ID like so <$widget id=foo> or <<macro id=foo>>. So one specific use case would be to "extract (=transclude?) the output from widget with id=foo from tiddler bar"

Defining a macro like \define foo(id) <$id$>bar</$id$> to create an arbitrary "tag" (I believe this is allowed in html), and invoking the macro with <<foo myid>> results in this widget tree:

{
    "type": "widget",
    "children": [
        {
            "type": "macrocall",
            "children": [
                {
                    "type": "vars",
                    "attributes": {
                        "__id__": "myid"
                    },
                    "children": [
                        {
                            "type": "element",
                            "tag": "p",
                            "children": [
                                {
                                    "type": "element",
                                    "tag": "myid",
                                    "children": [
                                        {
                                            "type": "text",
                                            "text": "bar"
                                        }
...

It appears like the output text ("text": "bar") is conveniently close to the identifier ("tag": "myid"). So what is needed is some mechanism that takes the containing tiddler title and the identifier and then spits out the "text" value in the element children. - This sounds so straightforward (even if I couldn't implement it) that I'm wondering if I'm missing something - ?

...and, actually, if a 3d party is to extract data from a remote TW, then this is how they would do it, right? Or are there other entries? Phrased another way; would an API be based on this technique? (I have basically no idea how APIs are built so, yeah, if I look like a fool now then this is why).

[pmario]

...that could extract the text some ''bold'' text from the widget tree that results from this wikitext: some ''bold'' text ?

That's not how it needs to be done. As I wrote, we only need a "search the widget tree for the marker" and add that found object to the "transcluded" widget tree. That's it. The rest is done by the core. The only problem that can happen is a performance penalty, we don't know yet. .. The second thing is, that HTML purists will probably be not happy with a "pseudo-element" named "extract".

The 3rd and a very important thing is, that we need to know, what screen-readers do with such an element. ... They should ignore the "extract" element, but they should not ignore the content within in.

[twMat]

Oh! So that's even better!

The only problem that can happen is a performance penalty, we don't know yet.

Any way to know this without testing it? Qualified guesses? Do we do anything comparable elsewhere?

The second thing is, that HTML purists will probably be not happy with a "pseudo-element" named "extract".

Maybe a more established semantic element like embed or object or even var ?

The 3rd and a very important thing is, that we need to know, what screen-readers do with such an element. ... They should ignore the "extract" element, but they should not ignore the content within in.

I have no idea how screen readers handle other semantic elements but, again, maybe if we use a more established element.
Note that such elements can also contain further attributes to describe the content, for example data-description=...

What would you suggest as a next step for me in this? Should I raise an issue request? Post on the boards to see if anyone has thoughts? How do you feel about it as a concept?

[pmario]

Any way to know this without testing it? Qualified guesses? Do we do anything comparable elsewhere?

Yes, backlink handling used to use this mechanism, but is done with an indexer now, for performance reasons. The functions for the "old" algorithm are still in the core.

[pmario]

What would you suggest as a next step for me in this? Should I raise an issue request? Post on the boards to see if anyone has thoughts? How do you feel about it as a concept?

I do have the feeling, that it will cause problems all over. I do like the field-approach more, even if it means to create a new editor as you did with your "super-tiddler" approach

[pmario]

I personally think, that the need to have a "pseudo-element" in the wikitext doesn't feel right. On the other hand this would be an easy fix with some "custom markup" ... But my "custom markup" plugin has a steep learning curve on its own.

[twMat]

BTW, I asked previously apropos "field-types" and my concern that the user should not have to do be distracted with technicals when authoring:

How about this: Default is p (or div?) but the system detects (i.e reads) the first word or characters and if it matches a predefined type, then this field type is set! E.g if the first row says !!foo bar the field type is set to h2, and if it is [img[ then e.g some style is applied. Etc.

Maybe if the segment ends with some terminating string or char it resets to p for next segment and if there is no termination then it repeats the previous field-type for the next field. This way it would be simple to make e.g a bullet list or some other repetitive presentation.

Any thoughts on this? I understand it is not something that is created right away but what do you think of the idea overall? The technique to detect predefined strings as they are typed is actually something Saq and I have played with for a "popup autocompletion concept" (and it works!)... so for the "field approach concept" that we discuss here, this could mean that the user types his text freely and via an in-text command in the editor (e.g ===) he could either accesses a control to create a new field and set field-type, or with a specific command (e.g =li, =img etc) the new field + field-type could be created automatically!

Even if I have only tested Saqs Streams briefly, a main strength with the UI/UX is that it hides the underlying system and tech as much as possible. The subtiddlers are automatically created when the user does something that he would do anyway (i.e click Enter/newline). Elegant.

[AnthonyMuscio]

Mat,

I was experimenting with a field that one can edit from the view template in which you could type a "command" such as +fieldname[="value"] with [optional] and on enter it would create the field and [value]. Similarly if you placed a macro in there it would display a result or if the macro or field contained actions would be triggered on a click button then cleared/or retained.

It would be a form of command line in the browser.

eg

• caption={{!!title}} then edit the caption for brevity.
• A checkbox widget to toggle a field/tag.
  Tony