state mechanism and state tiddlers

[Mohammad]

Refereeing to recent discussion on The Good and Bad of qualify: https://groups.google.com/d/msg/tiddlywiki/51XMzmLGxfQ/PLkfWWthBAAJ

We know many cases in creating User Interfaces (UI) needs some state tiddlers.

I got used to call  qualify for such cases, but with the recent discussion it seems qualify is NOT designed for purposes one like to keep some states permanently and irrespective of current tiddler situation.

Mat proposed a slugify operator. Also the Mario unique ID plugin is a potential tool here

My question is:

Is there any other ways to create unique stateTiddler? I dont mean do this manually?

There are situation, one needs permanent state tiddler to keep data. For example in Shiraz dynamic table I uses state tiddler to keep footer data or row styles.

These are not temporary data and it is tedious to define unique state tiddler for every table!

The current mechanism I use is qualify macro which is not good for all scenario.

--Mohammad

p.s:

 One KISS solution is to use a helper function which calls now macro with [UTC]YYYY0MM0DD0hh0mm0ssXXX format to create a unique title for the required state tiddler.

[Mohammad]

This solution by Jed Carty may be another starting point.

[Mohammad]

also https://tiddlywiki.com/prerelease/#unusedtitle%20Macro by Jed as core macro!

[Mohammad]

This is a macro to be clicked and manually create a title for state tiddler.

\define create_id_from_timedata(prefix) $prefix$-<<now [UTC]YYYY0MM0DD0hh0mm0ssXXX>>


\define uniqueId(prefix:id)
<$wikify name=id text=<<create_id_from_timedata """$prefix$""">>  >
<$button class="tc-btn-invisible" message="tm-copy-to-clipboard" param=<<id>> >
 {{$:/core/images/copy-clipboard}} create unique id
</$button>
</$wikify>
\end

call it like

<<uniqueId mystate>>

The most important drawback is: it is manual!

What do you think?

--Mohammad

On Monday, February 10, 2020 at 3:44:40 PM UTC+3:30, Mohammad wrote:

Refereeing to recent discussion on The Good and Bad of qualify: https://groups.google.com/d/msg/tiddlywiki/51XMzmLGxfQ/PLkfWWthBAAJ

We know many cases in creating User Interfaces (UI) needs some state tiddlers.

I got used to call  qualify for such cases, but with the recent discussion it seems qualify is designed for purposes one like to keep some states permanently and irrespective of current tiddler situation.

[PMario]

On Monday, February 10, 2020 at 1:14:40 PM UTC+1, Mohammad wrote:

Refereeing to recent discussion on The Good and Bad of qualify: https://groups.google.com/d/msg/tiddlywiki/51XMzmLGxfQ/PLkfWWthBAAJ

We know many cases in creating User Interfaces (UI) needs some state tiddlers.

I got used to call  qualify for such cases, but with the recent discussion it seems qualify is designed for purposes one like to keep some states permanently and irrespective of current tiddler situation.

 

I know it's not a real solution for your request but anyway:

I did create a PR at github, that allows the qualify-macro to use a isUnique parameter. So you can use

<<qualify "my-unique-title" isUnique:"yes">> .. So the macro doesn't add -123456 string. It returns the input state text.

 

My question is:

Is there any other ways to create unique stateTiddler? I dont mean do this manually?

Sure - but we didn't find it - yet ;)

 

There are situation, one needs permanent state tiddler to keep data. For example in Shiraz dynamic table I uses state tiddler to keep footer data or row styles.

These are not temporary data and it is tedious to define unique state tiddler for every table!

As I wrote, you need to work with variables like tiddler-names, tab-names, list-items and so on. ... And yes creating "real" uniqueness is hard, if it should be predictable.

 

The current mechanism I use is qualify macro which is not good for all scenario.

that's right.

 

p.s:

 One KISS solution is to use a helper function which calls now macro with [UTC]YYYY0MM0DD0hh0mm0ssXXX format to create a unique title for the required state tiddler.

... And you can remember their names, if you have many of them?

-mario

[Mohammad]

Many tanks Mario!

On Monday, February 10, 2020 at 5:12:04 PM UTC+3:30, PMario wrote:

On Monday, February 10, 2020 at 1:14:40 PM UTC+1, Mohammad wrote:

Refereeing to recent discussion on The Good and Bad of qualify: https://groups.google.com/d/msg/tiddlywiki/51XMzmLGxfQ/PLkfWWthBAAJ

We know many cases in creating User Interfaces (UI) needs some state tiddlers.

I got used to call  qualify for such cases, but with the recent discussion it seems qualify is designed for purposes one like to keep some states permanently and irrespective of current tiddler situation.

 

I know it's not a real solution for your request but anyway:

I did create a PR at github, that allows the qualify-macro to use a isUnique parameter. So you can use

<<qualify "my-unique-title" isUnique:"yes">> .. So the macro doesn't add -123456 string. It returns the input state text.

 

Are these unique permanent state or will be changed from session to another session or different position of host tiddler in the widget tree?

 

My question is:

Is there any other ways to create unique stateTiddler? I dont mean do this manually?

Sure - but we didn't find it - yet ;)

 

There are situation, one needs permanent state tiddler to keep data. For example in Shiraz dynamic table I uses state tiddler to keep footer data or row styles.

These are not temporary data and it is tedious to define unique state tiddler for every table!

As I wrote, you need to work with variables like tiddler-names, tab-names, list-items and so on. ... And yes creating "real" uniqueness is hard, if it should be predictable.

 

The current mechanism I use is qualify macro which is not good for all scenario.

that's right.

 

p.s:

 One KISS solution is to use a helper function which calls now macro with [UTC]YYYY0MM0DD0hh0mm0ssXXX format to create a unique title for the required state tiddler.

... And you can remember their names, if you have many of them?

My use case is to put some table properties created interactively by user when Shiraz dynamic table is used. Each table uses a state tiddler like $:/keepstate/dtable/xxx/xxxx/???

so, one time is created I do not need to explicitly refer to it!

I cannot use variable or fields here, as I do not know how many tables a user created per tiddler.

-mario

Thank you again 

[PMario]

On Monday, February 10, 2020 at 3:07:06 PM UTC+1, Mohammad wrote:

On Monday, February 10, 2020 at 5:12:04 PM UTC+3:30, PMario wrote:

.....

 I know it's not a real solution for your request but anyway:

I did create a PR at github, that allows the qualify-macro to use a isUnique parameter. So you can use

<<qualify "my-unique-title" isUnique:"yes">> .. So the macro doesn't add -123456 string. It returns the input state text.

 

Are these unique permanent state or will be changed from session to another session or different position of host tiddler in the widget tree?

It basically is a "title-pass-through". So the user has to make the title unique. ... The advantage is, that there is a new parameter isUnique

Eg: the core tabs macro uses the <<qualify "$state$">> in the macro code. .. The problem now is, that as a developer I need to change the core tabs macro if I don't want the default behaviour of the qualify macro. ...

If you have a look at the PR, I also changed the core tabs macro like so: <<qualify "$state$" "$isUnique$">> .. and the tabs macro gets a new parameter isUnique too. .. So no need to change the core tabs macro anymore, just to give it a state with a different behaviour.

.....

 

My use case is to put some table properties created interactively by user when Shiraz dynamic table is used. Each table uses a state tiddler like $:/keepstate/dtable/xxx/xxxx/???

so, one time is created I do not need to explicitly refer to it!

I cannot use variable or fields here, as I do not know how many tables a user created per tiddler.

Can you provide a link to some of your state creation tiddler and some code that uses those macros? .. I have no idea what Shiraz tables do and how they are created.

The qualify macro code has a "hidden feature" that isn't exposed to wiki users. ... It creates the unique hash based on the "transclusion" variable in the widget tree. ... transclusion is the default variable name defined by the code.

This variable name could be assigned by users, but the qualify macro doesn't use this name atm. .. I did experiment, if it could be used to create predictable unique states. ... BUT the mechanism only creates headaches.

-m

[Mohammad Rahmani]

Best wishes

Mohammad

On Mon, Feb 10, 2020 at 7:07 PM PMario <pmar...@gmail.com> wrote:

On Monday, February 10, 2020 at 3:07:06 PM UTC+1, Mohammad wrote:

On Monday, February 10, 2020 at 5:12:04 PM UTC+3:30, PMario wrote:
.....

 I know it's not a real solution for your request but anyway:

I did create a PR at github, that allows the qualify-macro to use a isUnique parameter. So you can use

<<qualify "my-unique-title" isUnique:"yes">> .. So the macro doesn't add -123456 string. It returns the input state text.

 

Are these unique permanent state or will be changed from session to another session or different position of host tiddler in the widget tree?

It basically is a "title-pass-through". So the user has to make the title unique. ... The advantage is, that there is a new parameter isUnique

Eg: the core tabs macro uses the <<qualify "$state$">> in the macro code. .. The problem now is, that as a developer I need to change the core tabs macro if I don't want the default behaviour of the qualify macro. ...

If you have a look at the PR, I also changed the core tabs macro like so: <<qualify "$state$" "$isUnique$">> .. and the tabs macro gets a new parameter isUnique too. .. So no need to change the core tabs macro anymore, just to give it a state with a different behaviour.

.....

 

My use case is to put some table properties created interactively by user when Shiraz dynamic table is used. Each table uses a state tiddler like $:/keepstate/dtable/xxx/xxxx/???

so, one time is created I do not need to explicitly refer to it!

I cannot use variable or fields here, as I do not know how many tables a user created per tiddler.

Can you provide a link to some of your state creation tiddler and some code that uses those macros? .. I have no idea what Shiraz tables do and how they are created.

I will push a new update but at the moment you can find these macros here

https://kookma.github.io/TW-Shiraz/#demo%2Fdynamic-tables-numerical-summary:demo%2Fdynamic-tables-numerical-summary%20demo%2Fdynamic-tables%2Fcustom-numerical-summary%20demo%2Fdynamic-tables%2Ftransclusion

A table is created using table-fd macro. Then the use in UI wants to add numerical summary like average of midterm score.

These summaries are stored in a state tiddler like keepstate defined like below

\define keepstate() $:/keepstate/dynamictables/$(currentTiddler)$/$(stateTiddler)$

and currentTable is a variable defined as

currentTable=<<qualify $stateTiddler$>>

Two issues here

- if in another session qualify generate another cryptic string, then table will lose its connection to its state

- if one rename the host tiddler the connection to state tiddler breaks again! BUT thanks to relink plugin, if it installed this issue has gone!

- if the host tiddler (the one has a dynamic table) is transcluded through tabs, scripts, ... again the currentTable variable will change (a consequence of qualify macro behavior) again table will lose its stateTiddler (this case is partially addressed in Shiraz)

I thought the kind of stateTiddler required in cases like dynamic tables is of permanent type! if they removed (like $:/state and $:/temp) when

a session is terminated or their title changed because of qualify working mechanism

The qualify macro code has a "hidden feature" that isn't exposed to wiki users. ... It creates the unique hash based on the "transclusion" variable in the widget tree. ... transclusion is the default variable name defined by the code.

This variable name could be assigned by users, but the qualify macro doesn't use this name atm. .. I did experiment, if it could be used to create predictable unique states. ... BUT the mechanism only creates headaches.

-m

--
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/a6ded49c-677e-4e38-85ac-985a4216a0e8%40googlegroups.com.

[Mohammad]

On Monday, February 10, 2020 at 7:07:06 PM UTC+3:30, PMario wrote:

On Monday, February 10, 2020 at 3:07:06 PM UTC+1, Mohammad wrote:

On Monday, February 10, 2020 at 5:12:04 PM UTC+3:30, PMario wrote:
.....

 I know it's not a real solution for your request but anyway:

I did create a PR at github, that allows the qualify-macro to use a isUnique parameter. So you can use

<<qualify "my-unique-title" isUnique:"yes">> .. So the macro doesn't add -123456 string. It returns the input state text.

 

Are these unique permanent state or will be changed from session to another session or different position of host tiddler in the widget tree?

It basically is a "title-pass-through". So the user has to make the title unique. ... The advantage is, that there is a new parameter isUnique

Eg: the core tabs macro uses the <<qualify "$state$">> in the macro code. .. The problem now is, that as a developer I need to change the core tabs macro if I don't want the default behaviour of the qualify macro. ...

If you have a look at the PR, I also changed the core tabs macro like so: <<qualify "$state$" "$isUnique$">> .. and the tabs macro gets a new parameter isUnique too. .. So no need to change the core tabs macro anymore, just to give it a state with a different behaviour.

.....

 

My use case is to put some table properties created interactively by user when Shiraz dynamic table is used. Each table uses a state tiddler like $:/keepstate/dtable/xxx/xxxx/???

so, one time is created I do not need to explicitly refer to it!

I cannot use variable or fields here, as I do not know how many tables a user created per tiddler.

Can you provide a link to some of your state creation tiddler and some code that uses those macros? .. I have no idea what Shiraz tables do and how they are created.

Another example is task manager example with dynamic table: 

https://kookma.github.io/TW-Shiraz/#demo%2Fdynamic-table%2Ftask-manager

It sets the style of row content in a stateTiddler and it needs to be permanent!

[TonyM]

Mohammad,

Personally I feel we have all the possibilities available to use already. 

• However I must ask where are you wanting to use state tiddlers? 
  I ask because arguably they usually relate to an open tiddler, but then if you want to toggle states one or more transclusions deep or in a macro unless you make use of the currentTiddler/storyTiddler something else is needed.
  

In relation to a recent post by you I went off working on bringing my tiddler serial number tool to the point of publishing. I bet you did not realise you often influence hours of work on my part. Unfortunately I have not finished it because there are some other pre-requisite changes that will make it far more professional (Custom actions for buttons). I also have other work today I must complete. Let me commit to the end of the week for this TSN solution. 

A Serial number, allocated automatically and/or only when needed allows you to create state tiddlers of the form "namespace/#/item" eg "$:/colors/2314/background" which could contain the background color for the tiddler with the serial number 2314. The serial number will be created and stored in the tiddler and will work regardless of what it is named in the future.

The advantage of this is the serial number is always unique unlike a tiddler title which is only unique at this point of time. Any prefix + a serial number is a unique tiddler.

Personally I have discovered a wide range of opportunities using serial numbers, I call them TSN's as Tiddler Serial numbers #tsn one example is;

• Have another form of shadow tiddler for any desired tiddler eg $:/shadow/#tsn in which a field that matches that in the original tiddler may contain a tooltip for that field in the original tiddler.

• Given the power of unique serial numbers other interesting ideas include a "virtual" word based serial numbers to generate/enforce unique variables or macro names.
• I also have a method to apply serial number without touching the tiddler, useful for core/shadow tiddlers which we do not normally rename anyway.

As usual my problem is too much coffee and too broad an imagination

Regards

Tony

[Mohammad]

Hi Tony,

 In this post https://groups.google.com/d/msg/tiddlywiki/MndGg5A0ib0/HucULW4PAAAJ I proposed a similar solution!

 That mean to use a macro to create a unique ID and then store in in id field of tiddler and use for tables like $:/keepstate/id/xxx

By the way I am interested to see how your solution work!

--Mohammad 

[Mohammad]

On Tuesday, February 11, 2020 at 1:08:07 AM UTC+3:30, TonyM wrote:

Mohammad,

Personally I feel we have all the possibilities available to use already. 

• However I must ask where are you wanting to use state tiddlers? 
  I ask because arguably they usually relate to an open tiddler, but then if you want to toggle states one or more transclusions deep or in a macro unless you make use of the currentTiddler/storyTiddler something else is needed.
  

This is true! I need permanent state tiddler! One can create them manually and prefix them with something like $:/keepstate if it is required to keep them hidden! but this is tedious!

So, I asked for a method to create permanent state tiddler with unique title!

Your TSN idea is great here! 

[PMario]

On Monday, February 10, 2020 at 5:51:03 PM UTC+1, Mohammad wrote:

..

I will push a new update but at the moment you can find these macros here

https://kookma.github.io/TW-Shiraz/#demo%2Fdynamic-tables-numerical-summary:demo%2Fdynamic-tables-numerical-summary%20demo%2Fdynamic-tables%2Fcustom-numerical-summary%20demo%2Fdynamic-tables%2Ftransclusion

A table is created using table-fd macro. Then the use in UI wants to add numerical summary like average of midterm score.

These summaries are stored in a state tiddler like keepstate defined like below

\define keepstate() $:/keepstate/dynamictables/$(currentTiddler)$/$(stateTiddler)$

and currentTable is a variable defined as

currentTable=<<qualify $stateTiddler$>>

Two issues here

- if in another session qualify generate another cryptic string, then table will lose its connection to its state

- if one rename the host tiddler the connection to state tiddler breaks again! BUT thanks to relink plugin, if it installed this issue has gone!

- if the host tiddler (the one has a dynamic table) is transcluded through tabs, scripts, ... again the currentTable variable will change (a consequence of qualify macro behavior) again table will lose its stateTiddler (this case is partially addressed in Shiraz)

I thought the kind of stateTiddler required in cases like dynamic tables is of permanent type! if they removed (like $:/state and $:/temp) when

a session is terminated or their title changed because of qualify working mechanism

hmm, I did have a very short 5min look at the code. So take everything with a grain of salt.

Reading your description and the code, I have the feeling, the whole thing is a little bit "over engineered".

eg: keepstate() seems to create a perfectly fine unique-state ... but currentTable=<<qualify $stateTiddler$>> destroys it.

I'll need to have a closer look, but I don't have the time atm.

-mario

[Mohammad]

Hi Mario

Well, I removed the qualify and just used static hard coded title. 

I'll need to have a closer look, but I don't have the time atm.

I will remain to receive your  further comments when you had time to have a closer look!

-mario

Thank you