$view widget new attribute : format="wikified"

[S. S.]

Could I please have some opinions on - if adding a wikified format to the $view widget so that:

<$view field="caption" format="wikified"/>

Would give the exact same result as:

{{!!caption}}

Then if this could result in a feasible solution for Github issues:

#3624 Table of Contents toc-caption macro awkward behaviour
#3753 list-links & list-links-draggable : issue with empty caption.

My idea is to propose the below solution as a fix for the issue of an empty caption field returning an empty result instead of the title:

<$view field="caption" format="wikified"><$view field="title"/></$view>

I do not have the capability to write the changes for a pull request myself, thus if this solution is found interesting, someone may implement it!

[TonyM]

S S,

I am not necessarily disagreeing with your suggestion however please consider this solution for captions and titles, noting that there is a link to the tiddler weather or not the caption is used

<$link to={{!!title}} tooltip="Click to open, View"><$view field="caption" format=text><$view field="title" format=text></$view></$view></$link>

but if you only want the result as text you can use a (side effect?) feature of the view widget 

that displays its content if no value is returned

<$view field="caption" format=text>
   <$view field="title" format=text></$view>
</$view>

Which on consideration is a very nice method by which to display something, such as the ability to create a field

if the field does not exist.

Regards

Tony

[S. S.]

Tony,

The method you describe cannot overcome this requirement:

the caption field is generally wikified (and so can include formatting etc.) while the title is rendered as plain text.

The two github issues linked to earlier, specially the older one (#3624 Table of Contents toc-caption macro awkward behaviour), discusses this in detail, and the reasons why other workable solutions have not been chosen yet.

[TonyM]

S s

I will revist this. I was doing something related and created something in the past that could have the answer.

So you are keen on loading the caption you want wikified?

Regards
Tony

[S. S.]

It has been stated that this is the expected  behaviour in TiddlyWiki, and I believe it is the wanted & backward-compatible behaviour too.

The solution also needs to be as uncomplicated as possible because as mentioned in #3624 :

We don't want to make the core toc-caption macro too complicated because it is typically rendered many times.

So the below solution was not found suitable :

<$list filter="[all[current]has[caption]]"
      emptyMessage="""<$view field="title"/>""">
      <$transclude field="caption"/>
</$list>

Regards

[Jeremy Ruston]

Hi SS

To answer your original question, there is a big difference between the view widget and the transclude widget.

The view widget computes and renders a single string. The transclude widget recursively renders the target tiddler.

That means that the view widget is a single item as far as the refresh mechanism is concerned. The results of the transclude widget, though, is a complete render tree, which can be selectively refreshed.

We do have three formats for the view widget that wikify the string: htmlwikified, plainwikified, and htmlencodedplainwikified. These are all used deep in the saving process where refreshing isn't a concern.

Best wishes

Jeremy

[S. S.]

Thanks Jeremy.

My knowledge of the innards being so limited, I make mistakes in choosing how to properly convey my ideas.

It looks like all of the format attributes remove the html or return it in text. I am looking for the html not to be removed.

I believe I am trying to see if the $view widget could have a format attribute (say called): wikified

The description of what it does would perhaps be: The field is wikified according to the mode attribute and the resulting HTML returned (ie HTML elements will NOT be removed)

[Jeremy Ruston]

Hi SS

My knowledge of the innards being so limited, I make mistakes in choosing how to properly convey my ideas.

It looks like all of the format attributes remove the html or return it in text. I am looking for the html not to be removed.

OK, just to be clear, the format “htmlwikified” will give you the HTML resulting from wikifying the target text. You get back the entire HTML string including tags.

What do you mean by the HTML not being removed? Can you show a snippet of wikitext with the output you’re looking for?

I believe I am trying to see if the $view widget could have a format attribute (say called): wikified

The description of what it does would perhaps be: The field is wikified according to the mode attribute and the resulting HTML returned (ie HTML elements will NOT be removed)

It sounds like a description of the transclude widget….

Best wishes

Jeremy

On Thursday, February 7, 2019 at 6:35:09 PM UTC+7, Jeremy Ruston wrote:

Hi SS

To answer your original question, there is a big difference between the view widget and the transclude widget.

The view widget computes and renders a single string. The transclude widget recursively renders the target tiddler.

That means that the view widget is a single item as far as the refresh mechanism is concerned. The results of the transclude widget, though, is a complete render tree, which can be selectively refreshed.

We do have three formats for the view widget that wikify the string: htmlwikified, plainwikified, and htmlencodedplainwikified. These are all used deep in the saving process where refreshing isn't a concern.

Best wishes

Jeremy

On Wednesday, February 6, 2019 at 4:53:53 AM UTC, S. S. wrote:

Could I please have some opinions on - if adding a wikified format to the $view widget so that:

<$view field="caption" format="wikified"/>

Would give the exact same result as:

{{!!caption}}

Then if this could result in a feasible solution for Github issues:

#3624 Table of Contents toc-caption macro awkward behaviour
#3753 list-links & list-links-draggable : issue with empty caption.

My idea is to propose the below solution as a fix for the issue of an empty caption field returning an empty result instead of the title:

<$view field="caption" format="wikified"><$view field="title"/></$view>

I do not have the capability to write the changes for a pull request myself, thus if this solution is found interesting, someone may implement it!

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/93247384-7729-4345-98a4-78f7b38560c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[S. S.]

Hello Jeremy

On Friday, February 8, 2019 at 10:48:44 PM UTC+7, Jeremy Ruston wrote:

OK, just to be clear, the format “htmlwikified” will give you the HTML resulting from wikifying the target text. You get back the entire HTML string including tags.

What do you mean by the HTML not being removed? Can you show a snippet of wikitext with the output you’re looking for?

I do not have a particular snippet of wikitext - I am trying to ensure a general solution. Right now I am using this as a test in the caption field:

R^^2^^D^^2^^ //isn't// Real - {{NewTid}}

By "the html not to be removed" I believe I meant "rendered" so that it would display exactly as would:

{{!!caption}}

 

I believe I am trying to see if the $view widget could have a format attribute (say called): wikified

The description of what it does would perhaps be: The field is wikified according to the mode attribute and the resulting HTML returned (ie HTML elements will NOT be removed)

It sounds like a description of the transclude widget….

And yes, you are right! It sounds like the transclude widget - parses and renders a string of text

I am trying to take advantage of this behaviour of the $view widget: The content of the <$view> widget is displayed if the field or property is missing or empty.

I need an efficient fast way to do the below as it may need to be done many (hundreds) of times on a refresh.

• To view a field (parsed and rendered), but if it's empty, to view another field (format=text).

I think a wikified format for the view widget may be an acceptable solution.

Thanks for following this.

[Jeremy Ruston]

Hi SS

As mentioned above, the view and transclude widgets work in a totally different way. Making the view widget behave like the transclude widget doesn't make sense because it would *be* the transclude widget.

The behaviour you describe is already available via the transclude widget. So how would the behaviour of the proposed "wikified" format of the view widget differ from the existing behaviour of the transclude widget?

Best wishes

Jeremy

--

Jeremy Ruston

jer...@jermolene.com

https://jermolene.com

--

You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/e15b0af8-0c80-464f-a044-92bbed0d0ee1%40googlegroups.com.

[S. S.]

Jeremy,

You are right, the requested wikified format of the <$view> widget would not differ from the wikified behaviour of the <$transclude> widget.

But I believe it would be an efficient way to take advantage of this difference shown below:

The TranscludeWidget treats any contained content as a fallback if the target of the transclusion is not defined (ie a missing tiddler or a missing field).

The content of the <$view> widget is displayed if the field or property is missing or empty.

The difference is that for the <$view> widget, the fallback content displays when the field is empty.

The alternate would be to use a <$list> widget, which I believe is much less efficient to catch this scenario a few hundred times during a refresh (as mentioned by you on github : We don't want to make the core toc-caption macro too complicated because it is typically rendered many times.}

It is similar to the way I think the below two are the same?

<$text text={{!!caption}}/>

<$view field="caption" format="text"/>

I hope that explains why I am making this suggestion.

Regards

[S. S.]

At present:

The $transclude widget treats any contained content as a fallback if the target of the transclusion is not defined (ie a missing tiddler or a missing field).

The content of the $view widget is displayed if the field or property is missing or empty.

It has been suggested to change the behaviour of the $transclude widget so that: it will treat a blank string the same as a missing field.

The reason is in this GitHub post by Jeremy and the comment preceeding it: Table of Contents toc-caption macro awkward behaviour

I vaugely recall mentions being made on the tiddlywiki Google groups where use is made of the difference in these two widgets to identify either an empty value or a missing field.

What might be the consequences of changing the behaviour of the $translcude widget as suggested?

[Jeremy Ruston]

Hi SS

I made a GitHub issue to discuss the potential change to the transclude widget:

https://github.com/Jermolene/TiddlyWiki5/issues/3843

Best wishes

Jeremy

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/f21ad4a0-4ed4-4215-b10d-31112d5b9384%40googlegroups.com.

[S. S.]

There was a message on the tiddlywiki Google groups today that resurrected an old post - that surprised me!

It referred to an extinct github issue #121 which included THIS POST:

<$view field="…" format="wikified"> is no longer supported. It was an early inconsistency that format="wikified" was a pseudonym for transclusion. You'll notice that the remaining formats for the view widget all result in a simple string being inserted into the widget tree, not a subtree, as occurs with transclusion.

Ha! The $view widget used to have the wikified format! And the reason it no longer does so is explained! Now your earlier statement falls into place:

To answer your original question, there is a big difference between the view widget and the transclude widget.

The view widget computes and renders a single string. The transclude widget recursively renders the target tiddler.

That means that the view widget is a single item as far as the refresh mechanism is concerned. The results of the transclude widget, though, is a complete render tree, which can be selectively refreshed.

The light finally shines!

Would be great then to see if its safe to implement : https://github.com/Jermolene/TiddlyWiki5/issues/3843 : Should the transclude widget treat empty text the same as missing text

Cheers!

To unsubscribe from this group and stop receiving emails from it, send an email to tiddly...@googlegroups.com.

[Jeremy Ruston]

Hi SS

Very good sleuthing! One of the pleasures of working on a project for so long is that I frequently come across things I wrote of which I have no direct memory (including code); one ends up having a funny sort of relationship with ones past self almost as if they were a different person.

Best wishes

Jeremy

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.

To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/b6e51eee-f726-424c-90ce-9b08a0dd3cfa%40googlegroups.com.