On Friday, April 23, 2021 at 3:57:13 PM UTC+2 [email protected] 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:2021091*4*
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
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/445b7ea0-5c96-4ca2-a99b-33075b634dc3n%40googlegroups.com.
