[TWX] Ubiquitous hooks

[Mat]

As you know, we can add e.g a viewtemplate by tagging anything "$:/tags/ViewTemplate" and there are other system tags that enable similar "appendings" to various generated lists.

Well, a post by @TonyM inspired further thoughts.. Basically Tony wants a "hook" so he can add stuff to the special fields area in the edit templates.

But wouldn't it make sense to generalize this so that anything can be placed anywhere? It should not be necessary to have an explicit ListWidget in only certain "container tiddlers"; instead any tiddler could be a potential "list-start" that other tiddlers can be prepended or appended onto. We are currently pretty limited in this regard.

Similar to current system tags, this could be interfaced by means of special "append:" and "prepend:" tags, such as "append:$:/core/ui/EditTemplate/fields". (Maybe it would also have to be tagged $:/tags/ViewTemplate ?)

Or perhaps something analogous to the "list-after"/"list-before" fields; you merely add a "prepend" or an "append" field with some other title as value, and it shows up there.

This could also make things more finely granular. Something like the mentioned fields template is pretty complex, not to mention the whole sidebar. Finer granularity allows for easier customization and less overwriting of shadow tids.

<:-)

[TonyM]

Mat,

Great Idea, however I would like to urge such special fieldnames not have generic names but have a prefix eg tw-append tw-append to 

I wanted to put a question to the devs that everywiki has fields such as listed here https://tiddlywiki.com/#TiddlerFields

It seems inappropriate to have fields such as 

footer

FooterField

The footer text for a wizard

library

LibraryField

If set to "yes" indicates that a tiddler should be saved as a JavaScript library

name

NameField

The human readable name associated with a plugin tiddler

source	SourceField	The source URL associated with a tiddler
subtitle	SubtitleField	The subtitle text for a wizard

Being listed as having such limited applications when in fact there may be many reasons to use these fieldnames in regular tiddlers.

Since I am working on making fields a first class citizen it is the above conventions that overlap a universal field idea.

Regards

Tony

[Mat]

TonyM wrote:

Great Idea, however I would like to urge such special fieldnames not have generic names but have a prefix eg tw-append tw-append to 

Yeah. My proposal is about the broader idea to have "ubiquitous hooks" on all visual parts. The examples are just to clarify, they're not real suggestions.

 

I wanted to put a question to the devs that everywiki has fields such as listed here https://tiddlywiki.com/#TiddlerFields

 

(...and then you mention several fictional field examples) 

I'm not sure where you're going with this comment. And it seems OT to what my proposal is about, no?

<:-)

[Mat]

CLARIFICATION of OP

I expressed something poorly.

But wouldn't it make sense to generalize this so that anything can be placed anywhere? It should not be necessary to have an explicit ListWidget in only certain "container tiddlers"; instead any tiddler could be a potential "list-start" that other tiddlers can be prepended or appended onto. We are currently pretty limited in this regard.

I didn't mean "any tiddler", I meant; any visual component. And by "visual component" I mean visually identifiable "objects" such as tiddlers, fields, widgets (more?) where it can be relevant to inject something.

<:-)

[TonyM]

Mat,

Perhaps my answer was too short, to make clear what I was trying to say.

 

Yeah. My proposal is about the broader idea to have "ubiquitous hooks" on all visual parts. The examples are just to clarify, they're not real suggestions.

and my example shows examples already using generic names for fields that serve specific purposes as would your proposed "hooks" when using fields. An example would be the append and prepend fields you mention.

 

I wanted to put a question to the devs that everywiki has fields such as listed here https://tiddlywiki.com/#TiddlerFields

 

(...and then you mention several fictional field examples) 

 

What are the fictional examples I gave?, All the listed fields are documented as such, to me the source field does not necessarily mean "The source URL associated with a tiddler", yet the user is told in the doco that this is what it means.

I'm not sure where you're going with this comment. And it seems OT to what my proposal is about, no?

I think perhaps it is a side topic, not off topic and is a suggested condition for your proposed solution. An example may be since your "ubiquitous hooks" [are] on all visual parts" that the related fields are prefixed "ui-" for user interface, imagine a field called ui-list on any tiddler that would transclude the listed items just as the view-template does its items tagged $:/tags/ViewTemplate, or a ui-viewtemplate field that specified an alternate view template for the current tiddler.

I would be in favour of moving tags into field values where possible since tags are key to the users experience of  a non-linear personal web notebook.

As I said before  the current conventions overlap a universal field idea. Providing Ubiquitous hooks also needs to be "universal" and should avoid overlap.

<:-)

I hope that helps, I in know way want to interfere with your interesting ideas,

Regards

Tony  

[Mat]

What are the fictional examples I gave?, All the listed fields are documented

My bad. Had not seen this in the docs previously.

...

Anyway, regarding fields per se, your points probably make sense. My overall proposal is for "TWX" (an imaginary one-sunny-day version of TW) and I don't know if an actual implementational solution would involve fields at all.

<:-)

[TonyM]

Mat,

I understood, you were not targeting any tiddler, but a global solution that supports the visual components as well as other use cases, is what I am ading. The fact is this mechanism to use a set of tags to determine what appears is not only increasing pervasive in the core but a smart thing to do when developing our own solutions and plugins. I would add the ability to pass a filter into it and it would have a great utility. I have also done something similar with fields in the current tiddler in mymenus plugin. Personaly I am always looking to universalise changes since it is in keeping with TiddlyWikis whole architecture, just as your proposal so anything can be placed anywhere.

Regards

Tony

[Jeremy Ruston]

Hi Mat

The system tags like $:/tags/ViewTemplate are implemented by a fragment of wikitext like this:

<$list filter="[all[shadows+tiddlers]tag[$:/tags/ViewTemplate]!has[draft.of]]" variable="listItem"><$transclude tiddler=<<listItem>>/></$list>

It sounds like your OP is a proposal to make that construction pervasive by effectively turning every transclusion within the core templates into an instance of that construction.

On the face of it, the problem is that each of those transclusions would have to get a little more complicated in order to include information about the system tag that is to be used to extend it.

Another issue is that pulling in tiddlers by tag is significantly less efficient than transcluding a single tiddler. Therefore we don’t want to pay the price for that work unless we need it. That means that we need to explicitly mark up the transclusions that should be extensible in this manner, which brings us straight back to the present way of things.

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/a9e0817b-c5ff-419f-8544-11fd7f47207d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mat]

Jeremy; 

I assumed an underlying js implementation for transclusion would be a more economical construct but, nevertheless, the end goal with full topological control is what matters so how about this idea:

Everything is target'able via an address (e.g <tiddler>.<field> or <tiddler>.<item-id> or similar. Then, when you want to add something you basically just address it to that place...

...and it gets its own address by appending whatever it might be onto the previous address.

In one sense this should be achievable with CSS (where, of course, targetting is a main activity) but the described idea would make it innate to TW and the syntax could be simple as pie compared to CSS.

Assuming TWX still has widgets with the same syntax;

<$inject item="myreference" where="MyTiddler|myfield|right-side"/>

<:-)