Field declaration in Tiddler

[Ray Vermey]

Hi all

I dont know if it yet exists but i would like to know if it is possible to 

create (or fill existing) fields within a tiddler.

Like:

This is my text i write in the tiddler about subject so and so

@fieldname:value (for instance: @due-date:20210912 and that field due-date is created

or filled with value 20210912)

If possible more than 1 field in a tiddler.

Is that possible??

Thanks

Ray

[PMario]

On Thursday, April 22, 2021 at 1:24:45 PM UTC+2 rayv...@gmail.com wrote:

I dont know if it yet exists but i would like to know if it is possible to 

create (or fill existing) fields within a tiddler.

Everything is possible. (almost ;) ...

This is my text i write in the tiddler about subject so and so

@fieldname:value (for instance: @due-date:20210912 and that field due-date is created

or filled with value 20210912)

If possible more than 1 field in a tiddler.

I think, there is a plugin somewhere, that knows how to create tags in a similar way.

https://ibnishak.github.io/Tesseract/pluginsandmacros/hashtag2tag.html ... found it, but don't know if it still works ;)

-mario

[Charlie Veniot]

To paraphrase what I always told my users in the twenty-five year career I loved:

"We can get TiddlyWiki to do anything short of pumping out toast!"

[PMario]

On Thursday, April 22, 2021 at 1:24:45 PM UTC+2 rayv...@gmail.com wrote:

@fieldname:value (for instance: @due-date:20210912 and that field due-date is created

Just a thought.

In TW we have the date format options to creat "nice looking" date strings, but we don't have a way to do this:

Fr. Apr. 23 11:10  >  20210423091025  because TW uses UTC time internally.

IMO it would be nice to use a Journal title and convert it back to a field eg: due-date: 20210912   which then can be shown in a different format if it needed.

.... Just a thought.

-mario

[Ray Vermey]

So Charlie, tell me, can it be done, what i want? On the fly? :-)

Ray

Op vr 23 apr. 2021 om 04:22 schreef Charlie Veniot <cj.v...@gmail.com>:

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/245c3f25-dce0-4c97-bb70-b2548ddc271en%40googlegroups.com.

[Charlie Veniot]

But then I would sometimes qualify, responding to users, with a "but it's going to cost ya."

With a soupçon of (i.e. a whiff) "just because we can do it doesn't mean we should."

I'm thinking some javascript would be necessary.  Javascript and I do not along get.

I do have thoughts about doing this via pure/pristine TiddlyWiki magic.

• One would involve a "process this tiddler's content" button to parse through the entire content of the tiddler's text and then turn into fields whatever looks like fields.  So not at all on the fly.
• The other would wrapping every field with a transclusion (using your example:  {{value@fieldname||MakeField}} ), which would plop a button right there for you to press on (after save of a tiddler) which would create the field in the tiddler and put the value in the field.  From that point on, the transclusion would display the value from the field instead of a button.  Again, not on the fly.
  • A macro could be used instead, but it would be the same result, so just a matter of personal preference re transclusion versus macro (I always go transclusion unless there is a technical benefit to go macro instead)

Just like putting [[This New Tiddler]] in the text of some tiddler does not automatically create that non-existent "This New Tiddler" until one manually clicks on the link (i.e. manual intervention required to actually create the tiddler), the same goes with fields: manual intervention required.  That seems like a smart thing to me security-wise.  If full auto-creation of tiddlers and fields could happen, then imagine some malicious code madly auto-creating tiddlers and fields in a TiddlyWiki to the point of effectively causing a "denial of service" attack, totally locking/killing your TiddlyWiki.

With javascript, I'm betting it could be done.  But I'm thinking it might not be such a good idea.

[Charlie Veniot]

I imagine my brain as a bunch of hamsters spinning away in the far recesses of my subconscious mind.

Just when I manage to spell out my thoughts on something, after a little bit one of those damned hamsters spin out a "ah, but what about this?"

An alternate "save tiddler" button !  (Well, maybe alternate actions for existing save button, but I'm thinking that would be harder for some reason.)

This alternate "save tiddler" button would parse the text of a tiddler, replacing every @fieldname:value reference with creation of the field with that value and replacing with {{!!fieldname}}.

I think.

Something like that.  Might be ugly.  Might be slow.  Might not work at all.  But might work, with some serious rolling up of sleeves, untucking of all wedgies, and burning the midnight oil.

Or might be easy as pie.  Just waiting on any one of them hamsters to spin something at me.

[PMario]

On Friday, April 23, 2021 at 3:57:13 PM UTC+2 cj.v...@gmail.com wrote:

But then I would sometimes qualify, responding to users, with a "but it's going to cost ya."

With a soupçon of (i.e. a whiff) "just because we can do it doesn't mean we should."

I'm thinking some javascript would be necessary.  Javascript and I do not along get.

I did have a look at the "hash2tag" plugin. It was entirely done with wikitext, with a "super cool idea", treating the tiddler text as a list ...

It may cause some problems, if you use wikitext lists like eg:

#list

.... but would be OK with

# list

Similar things may happen to your @due-date:20210912 format. Especially if there will be some "text refactoring" ...

Eg: if you change your date from @due-date:20210912 to  @due-date:20210914 and the due-date field already exists.

From my point of view there should be a warning except if created is the same day. ... IMO it's common, that the due-date will change that day.

So yea. Some JS code will make it easier to implement "special" handling.

 

I do have thoughts about doing this via pure/pristine TiddlyWiki magic.

• One would involve a "process this tiddler's content" button to parse through the entire content of the tiddler's text and then turn into fields whatever looks like fields.  So not at all on the fly.

Right. At the moment the logic happens on a save "button click".

 

• The other would wrapping every field with a transclusion (using your example:  {{value@fieldname||MakeField}} ), which would plop a button right there for you to press on (after save of a tiddler) which would create the field in the tiddler and put the value in the field.  From that point on, the transclusion would display the value from the field instead of a button.  Again, not on the fly.
  • A macro could be used instead, but it would be the same result, so just a matter of personal preference re transclusion versus macro (I always go transclusion unless there is a technical benefit to go macro instead)

no. ... Makes it more complicated! ... BUT you are right. There needs to be some doc, that transcluding fields from other tiddlers shouldn't affect the "current tiddler" ... At least I thin it shouldn't ... BUT what if the transclusion is a {{||template}} :/

 

Just like putting [[This New Tiddler]] in the text of some tiddler does not automatically create that non-existent "This New Tiddler" until one manually clicks on the link (i.e. manual intervention required to actually create the tiddler), the same goes with fields: manual intervention required.

There are may users that want to have this behaviour. ... See all the threads about "roam look-a-likes"

 

  That seems like a smart thing to me security-wise.

I don't have security concerns here.

 

  If full auto-creation of tiddlers and fields could happen, then imagine some malicious code madly auto-creating tiddlers and fields in a TiddlyWiki to the point of effectively causing a "denial of service" attack, totally locking/killing your TiddlyWiki.

IMO not really.

 

With javascript, I'm betting it could be done.  But I'm thinking it might not be such a good idea.

Sure. But "search / replace" with regexp filter may be a "hot" wikitext candidate. In combination with the field-mangler widget.

-mario

[PMario]

As I wrote.

The biggest concerns I have is with "refactoring". ... With your current concept the wikitext will _always_ win. ...

But what if a user wants to have a nice GUI dialogue as done in Projectify [1]. The GUI may change the due-date from the view-mode.

But now we do have a difference between the "wiki text" and the field-value. ... How should this be resolved in a generic way, that makes sense.

-mario

[1] https://projectify.wiki/demo.html

[PMario]

On Friday, April 23, 2021 at 5:26:02 PM UTC+2 PMario wrote:

But what if a user wants to have a nice GUI dialogue as done in Projectify [1]. The GUI may change the due-date from the view-mode.

It could also be the user, who changes the field. eg:

 - At the very beginning there is "wikitext" only.

 - After the tiddler is edited the second time it looks like this:

What if the user changes the field, instead of the wikitext. :( .... So from a "users point of view" I would like to have  a 2 way connection.

From a "programmers point of view",  I would want to hide the field from the view and save it as an UTC encoded date, like created or modified. The advantage would be, that there is only 1 "source of truth" - The wikitext.

Or if not hidden, it may be "protected". So there needs to be an action like an "Edit this field and search / replace in the text" ... button.

just a thought!

mario

[TW Tones]

Ray,

As I understand it you can do this either when creating a tiddler, in a batch to apply it to all existing tiddlers, you can also use either new tiddler buttons containing fieldname="value", clone or use a template for new tiddlers. You could even setup a button to "update a tiddler", If you get cheeky you can build a system with all these methods available.

The nirvana is to respond when a tiddler is created/saved with actions to ensure it has the desired fields, values or prompts to provide the value.

As has being said before populate date fields using the tiddlywiki date serial number and use the view widget to view it in what ever way you want, otherwise you make parsing dates something you need to code.

I already have buttons that when displayed in a project tiddler will create a task tiddler with that project name set, and other relevant values. We could call this context driven creation of tiddlers. 

Regards

Tones