Make viewformats a new module-type

[flibbles]

This is my proposed crack at making the view widget's formats a module-type of their own. However, @Jermolene, I saw that you had a comment in the code saying:

The various formatter functions are baked into this widget for the moment. Eventually they will be replaced by macro functions

which makes me think you had something a little different in mind. And that's cool. Although I'm not sure what you meant by macro functions. If you show me what you mean, I can do that instead.

All I care about is that they are separated. My tw5-xml plugin would have loved to have defined it's own xmlencoded format type, as well as other personal plugins I've written, but mostly if I were to do my minify plugin, I'd need to be able to override some of these format types, and I'd rather be able to do that without overriding shadow tiddlers.

Your thoughts on this?

Quick note: If you merge #5383, this will conflict, but I'll happily take care of resolving it.

[flibbles]

So this PR fell by the wayside, but that's okay!! Because I've elaborated, and now the ViewWidget is even better!

I've introduced the same sort of notation as [all[shadows+tiddlers]]. You can chain formats to apply multiple transformations to the selected text. This actually means we can have fewer formats but be more versatile. Look at this.

Deprecate htmlcodedplainwikified. It's now plainwikified+htmlencoded Forget doubleurlencoded. We'd now use urlencoded+urlencoded

Of course those two would remain for backward compatibility reasons, but I honestly think this is better. It's completely compatible with what used to be, and it's clearer what these formats are doing. AND we no longer have to make all the different permutations. Did you know I once needed to plainwikify some text and use it as a javascript string. I couldn't. Because there was no jsencodedplainwikified, and you would have died a little inside if I'd asked us to add that. But now I can just use the format plainwikified+jsencoded.

But the REAL reason I'm suggesting this change is for extensibility. I'm just about finished with my TW5-Uglify plugin, and I want a view format jsuglify which compresses the text as though it were javascript. But then I started to add jsuglifyhtmlencoded and jsuglifyhtmlwikified, and then I realized there had to be a better way. This is that way.

But @Jermolene, I know you still had a comment about how you wanted to see ViewWidget implemented which mentioned macros. I'm absolutely down to change this PR to be in line with your vision.

Also, I added a bunch of tests, because there weren't any for ViewWidget formats and modes.

[flibbles]

Just to note, if you're okay with this idea, I still need to swap out uses of doubleurlencoded and htmlencodedplainwikified from the core. And also update the documentation. So it's not quite ready to merge.

[flibbles]

Okay. I've swapped out the few cases where "doubleurlencoded" was used with "urlencoded+urlencoded". And I updated the documentation. Hopefully I did all right with that. If not, let me know and I'll fix it.

Otherwise, this is Good to Merge!

[saqimtiaz]

@Jermolene thoughts?

@flibbles some conflicts to resolve.

[flibbles]

Conflicts are resolved. This is ready to merge.

... unless @Jermolene had some other design in mind, which I'm still happy to do if he did.

[Jermolene]

Hi @flibbles this is excellent, thank you.

The new ability to do things like format="urlencoded+urlencoded" is interesting, but it also makes it clear that we're close to reimplementing filter processing. To be specific, the functions in the new "view/formats" file can be seen as simplified filter operators.

That observation doesn't necessarily invalidate this PR, because we're obligated to retain the view widget, and so it still makes sense to clean up the implementation.

One could reformulate the view widget to use filters instead of the format attribute. (There are view formats that don't have a corresponding filter operator, but they could be added easily enough)

<$view tiddler="HelloThere" field="text" filter="[encodeuricomponent[]]"/>

And then we could change the implementation of the "format" attribute to be a shortcut syntax for common filter strings.

The end result would bring the view widget back from the cold, modernising it, and tucking away the behaviour that's unfortunate from a backwards compatibility point of view to just be a lookup table. Of course, it would still make sense to define the lookup table via a moduletype to keep things extensible.

[saqimtiaz]

@Jermolene excellent idea, use of filters here would offer a lot of flexibility.

[pmario]

<$view tiddler="HelloThere" field="text" filter="[encodeuricomponent[]]"/>

hmm, while it is a filter, I think it's confusing to see a filter parameter for the view macro.

If I see filter, I do expect a list. .. So I expect a multi line output here. Which isn't the case.

What about formatFilter or something that has a relation to the format parameter, where it came from

[Jermolene]

What about formatFilter or something that has a relation to the format parameter, where it came from

I agree, formatFilter would be better.

[flibbles]

So view as it is is... deprecated? Huh.

So this needs to make it so ViewWidget uses filters.

• It uses the "formatFilter" attribute if present as a filter for the incoming text block.
• If "formatFilter" is missing, it uses "format", which will contain a name that looks up hardcoded strings of common transformations.

Okay. If this is right, that makes sense. It seems useful, but are these equivalent?

<$view tiddler="X" field="text" formatFilter="[encodeuricomponent[]]" />

<$text text={{{ [[X]get[text]encodeUriComponent[]] }}} />

Also, what is the expected behavior if the formatFilter returns multiple results?

Also, is there a link to this filter processing reimplentation? I was unaware of it.

[Jermolene]

So view as it is is... deprecated? Huh.

We haven't yet been able to deprecate it because there are still things that it can do that can't easily be achieved in other ways, but that's where we're aiming.

The problem is that the view widget came really early on in TW5, before we had filters or a bunch of other stuff that we now take for granted. Along with things like the fieldmangler widget, the view widget bashed together lots of black box functionality that was only needed because TW5 lacked the native expressivity.

So this needs to make it so ViewWidget uses filters.

• It uses the "formatFilter" attribute if present as a filter for the incoming text block.

• If "formatFilter" is missing, it uses "format", which will contain a name that looks up hardcoded strings of common transformations.

That's correct.

Okay. If this is right, that makes sense. It seems useful, but are these equivalent?

<$view tiddler="X" field="text" formatFilter="[encodeuricomponent[]]" />



<$text text={{{ [[X]get[text]encodeUriComponent[]] }}} />

Yes, those two are equivalent. The text widget formulation is the primitive, and the view widget is a shortcut.

Also, what is the expected behavior if the formatFilter returns multiple results?

Same as the triple brace syntax for attributes, we'd just take the first result.

Also, is there a link to this filter processing reimplentation? I was unaware of it.

This is only a suggestion at present.

[pmario]

@flibbles ... Does this PR still work? @Jermolene ... IMO should be part of 5.2.0

[flibbles]

I think the last conclusion was that this PR is fixing something which is going to be deprecated, and thus isn't going in?

I don't know if this PR is the appropriate place to make the whole "ViewWidget uses filters" change.

[Jermolene]

Hi @flibbles @pmario this PR is still under consideration; I want to continue thinking through the implications of the thoughts above.