[TW5] Desirable core additions

[TonyM]

Folks,

Please forgive my being so brash to propose some TW5 core additions but I am in the middle of a learing curve that may inform some improvements to the core that will help others on this learning curve. I would liove your feedback and if you are a GitHub proficiant person for you to submitt them. First I will explain what I want with a small explination and hope the reasons prove self evident, however I will put a longer argument if requested. I acknowledge there may be a gap in my knowledge and are happy to be set straight. I am no Genius but I am not stupid and a clear way to do the following would have made adopting TW5 much easier. I hope I am using the correct terminology.

Psudo-Constants
Provide tools to create "constants" within a given tiddler and any sub-tiddlers (transcluded, called, macros etc...)
I have finaly learned I can do this using the below

\define currentobjectsrc()
{{!!title}}
\end
<$wikify name="currentobject" text=<<currentobjectsrc>>>

Such that <<currentobject>> has the same value in all sub-tiddlers

This is still not sufficent as <<currentobject>> can only be used in some places.

Why cant we have an established syntax that allows this as a built in feature?

The current methods are way to convoluted and I fear act as a barier to someone using tiddlywiki as their knowledge must be much deeper than it need be before they can do something most people will think of while they are learing about tiddlywiki. In this case much can be done without learning to navigate a lot of complexity by providing values that are not so context sencitive.

Edit fields in Current Tiddler
Provide the tools to edit fields in the Current Tiddler

The complexity of editing fields in the current tiddler, whilst it has its technical reasons, runs counter to the intuitive value of tiddlywiki. The most practical way is to use the tiddler edit function in which case the user has to see all possible fields and values. I would like to provide access to edit fields in the current tiddler through the View Template, without needing to use two additional tiddlers to achive this.

I understand the issue is the rendering of each key stroke and the loss of focus, but why can we not have a method where you nominate a field and its value is placedn in an external tiddler, you then edit the field value and on pressing a (field) save button, it is written back to the calling tiddler in one shot?

Once again the current methods are way to convoluted and I fear act as a barier to someone using tiddlywiki as their knowledge must be much deeper than it need be before they can do something most people will think of while they are learing about tiddlywiki.


Regards
Tony

[RichardWilliamSmith]

Hi Tony,

I'm sure I'm not alone in saying that I feel your frustration. I've been there lots of times - convinced that the thing I'm trying to do should be simple and yet not being able to find a way to do it. Often I find that whilst two things might seem equally complicated, one of them is trivial and the other is impossible. Such is life.

To help us address your first point, could you give a specific example of something that you feel the current syntax should be able to do and can't? Is it possible to get the desired behaviour by storing the values of your constants in tiddler fields and referring to them directly?

As to your second point; if you find any of the tiddlers tagged with $:/tags/EditTemplate (for example $:/core/ui/EditTemplate/fields) and add the tag $:/tags/ViewTemplate they will appear in the view template too. Maybe this is a little more crude than you were imagining? It can be improved upon by writing some UI of our own, if you have a specific idea of how you'd like it to work. Is this basically what you meant?

Regards,

Richard

[Mark S.]

Adding to what Richard suggests, if you only want your special fields to appear, you can make a tiddler with $:/tags/ViewTemplate and populate it with:

\define allmine(field)
<$list filter="[all[current]has[$field$]]">
$field$: <$edit-text tag="input" field="$field$"/>
</$list>
\end
<<allmine myfield>><br/>
<<allmine myfield2>>

Then just add as many <<allmine>> macros as special fields you have. You can type right into these without the focus problem.

Good luck,
Mark

[Danielo Rodríguez]

El miércoles, 9 de agosto de 2017, 6:14:48 (UTC+2), Mark S. escribió:

Adding to what Richard suggests, if you only want your special fields to appear, you can make a tiddler with $:/tags/ViewTemplate and populate it with:

You are missing the point that you CAN NOT edit a field on the current tiddler without losing the focus of the input field. Your solution is not different from any other 

[RichardWilliamSmith]

The method I suggested works without losing focus when tested on Tiddlywiki.com. I just tried transcluding the body element itself ($:/core/ui/EditTemplate/body) and that works too. I do remember there being an issue with losing focus when updating the content of a tiddler, as you describe, but this doesn't seem to be triggering it.

[RichardWilliamSmith]

Just to add that you can go to Tiddlywiki.com and create a new Tiddler with the text <$edit-text field="text"/> and give it the tag $:/tags/ViewTemplate you get a live edit field that doesn't lose focus. I guess the difference between this and an edit-text widget as part of the tiddler content (which does indeed lose focus on each keypress) is that the view-template "chrome" involves a layer of indirection (?).

[Arlen Beiler]

And, since no one mentioned it yet, the set widget is probably what you're looking for for pseudo constants. Documentation is on tiddlywiki.com.

On Aug 9, 2017 07:53, "RichardWilliamSmith" <richardwi...@gmail.com> wrote:

Just to add that you can go to Tiddlywiki.com and create a new Tiddler with the text <$edit-text field="text"/> and give it the tag $:/tags/ViewTemplate you get a live edit field that doesn't lose focus. I guess the difference between this and an edit-text widget as part of the tiddler content (which does indeed lose focus on each keypress) is that the view-template "chrome" involves a layer of indirection (?).

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7bac3621-bb1f-4c17-b28a-314c0b686d3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark S.]

You'll have to explain what you mean. The method I described doesn't lose focus.

[Mark S.]

Re request #2, use the following macro. Put it in a tiddler tagged $:/tags/Macro.

Then put <<editnsave myfield>> anywhere in the tiddler that you want to edit the field. This will create an edit field and a reset button. Use the * button the first time you use the field to synch it with the current values. Edit in the field. Press Save when you're done.

HTH
Mark

\define editnsave(field)
<$vars tid="$:/temp/$(currentTiddler)$" fld="$:/temp/$(currentTiddler)$!!$field$" fldx="{{$:/temp/$(currentTiddler)$!!$field$}}" >

$field$: <$edit tiddler=<<tid>> field="$field$"/>
<$button>*<$wikify name=val text="{{!!$field$}}"><$action-setfield  $tiddler=<<tid>> $field="$field$" $value=<<val>> /></$wikify>
</$button>
<$button>Save<$wikify name=val text="<<fldx>>"><$action-setfield  $field="$field$" $value=<<val>> /></$wikify>
</$button>

</$vars>
\end

[TonyM]

Thanks all for your comments,

I will investigate the possibilities here, However my key point is it should be fairly trivial to find a clear solution coded in the the core and documented thoroughly in the documentation.

My Key point is these basic needs are not addressed in the current tiddlywiki version except via convolutioted work arounds that demand too much knowledge that they are unavaialable to users until they understand a lot more. I have committed many hours learining Tiddlywiki because of my familularity with tiddlywiki classic and a passion for it, but I would expect such "missing features" to stop a lot of new users, giving up, and not returning.

Regards
Tony.

[TonyM]

Richard,

Thanks for your empathy.

The best example of the first case Psudo constants is in the post above, this works for me in subtiddlers however as it returns the constant only in the form <<currentobject>> it is still of limited value. Lets imagin I have a value it may even be the tiddler name I have open but it could be field value or any string and I want to make it available to all subtiddlers eg those included via tabs, or those transcluded into the current one.  There should be a simple set statement or other format which does this, and behaves similar to the <<currentobject>> above. In every case I have tried so far the values change depending on context, as a result of a filter, if used in a macro, a widget, send-message the tiddler in which it lays such that the same value needs to be handled and referenced in a range of different forms when it is clear as anything what I am trying to do, the mechanisium is just not there nor straitfroward. I use the term Psudo-constant because in my example <<currentobject>> is set in the "master" tiddler" and will be different or not exist in other tiddlers, but will be available in subTiddlers.

I will revisit the tag view template method you mention but again, the ability to edit fields in the same tiddler should simply be catered for in the core not requiring convolutted solutions.
eg edit-field-here fieldname with the self update issues adderessed behind the sceens,and if nessasary turning refresh transclusions off until enter, set or save button is pressed.

Of critical importiance, I now hove ways to do the above two things, but they are hard to use, unrelaiable and change with context all the time. The fact I can even ask for such featured is only after some 100hours of learining, and realising they are not there. Future users need this reduced to much less time.

I would also like to add a caviet, When I develop solutions I always try and develop reusable solutions so I am not keen on hard coding something such as "constants" that are context sensive because if you clone a tiddler they will no longer work. My phudo-constant addresses this, it can be set from a title or field name but remains constant below that.


Thanks
Tony

[TonyM]

Arlen

Please detail your usage of the set widget that would help because I ghave not yet being able to set a relaible psudo constant as what passes through is subseqently evaluated.

Thanks
Tony

On Wednesday, August 9, 2017 at 10:02:02 PM UTC+10, Arlen Beiler wrote:

And, since no one mentioned it yet, the set widget is probably what you're looking for for pseudo constants. Documentation is on tiddlywiki.com.

On Aug 9, 2017 07:53, "RichardWilliamSmith" <richardwi...@gmail.com> wrote:

Just to add that you can go to Tiddlywiki.com and create a new Tiddler with the text <$edit-text field="text"/> and give it the tag $:/tags/ViewTemplate you get a live edit field that doesn't lose focus. I guess the difference between this and an edit-text widget as part of the tiddler content (which does indeed lose focus on each keypress) is that the view-template "chrome" involves a layer of indirection (?).

--
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.

[TonyM]

Mark,

I am yet to test this but could it be extended as follows

<<editnsave myfield "stringvalue">>

But idealy
<<editnsave myfield "{{!!myfield}}">>

to prepopulate it?

It is often helpful to utilise the edit of a value to display it as well so that you can save screen realestate.


Regards
Tony

[Mark S.]

Here's an improved (?) version that uses the existing field value as a default:

\define editnsave(field)
<$vars tid="$:/temp/$(currentTiddler)$" fld="$:/temp/$(currentTiddler)$!!$field$" fldx="{{$:/temp/$(currentTiddler)$!!$field$}}" >

$field$: <$edit-text tiddler=<<tid>> field="$field$" default={{!!$field$}}  tag="input"/>

<$button>Save<$wikify name=val text="<<fldx>>"><$action-setfield  $field="$field$" $value=<<val>> /></$wikify>
</$button>

</$vars>
\end

[RichardWilliamSmith]

Hi Tony,

I really hope we can use your experiences as a further spur to improving the documentation for Tiddlywiki. It's something the community have been aware of a long time and which we have (imo) yet to seriously address. Some measure of the difficulty we experience in this regard is in determining just which functions are 'basic' and which are 'advanced'. Many things are possible with Tiddlywiki but the 'how to' runs the gamut from 'click things' to 'basically programming'. 

I think you'll find that the 'set' mechanism does basically what you want. It was added during development (I believe) to deal with a requirement like the one you have. What we need to work out is where and how that should be documented to save other people the frustration that you have had to deal with.

We need to move away from this terrible group platform to something that lets us start to construct a meaningful knowledge base.

Regards,

Richard

[TonyM]

Thanks Mark,

I am trying to use this now. I have duitfuly tagged it $:/tags/Macro saved and reloaded

in Both the key tiddler and below placed
<<editnsave objecttabs>> used other field names and ways of referencing the field name yet nothing apears.

I have looked around but can not see why this would not work, editnsave is not apearing in dumpvariables as would be expected

Thanks so far.

Tony

[@TiddlyTweeter]

Ciao TonyM

Good discussion you started. I read it with interest.

I'm  slightly laterally thinking on it ...

(1) -- revision of syntax would likely ONLY be possible in a major revision step ... i.e. for a TW6. So its a Longer Term aim?

(2) -- the recurrent documentation saga with TW is a complex Catch-22. Here works well enough when you are in the know. Its likely a put-off if you are visiting just trying to find your way. I think a big part of the issue is NUMBERS, NOT lack of will. I moaned a lot about "documentation" in the past. Many attempts have been made (e.g. serious ones in Reddit and StackExchange) . They have not fully fruited--though the StackExchange might if it can get more people using it regularly. I think the core issue its a LOW numbers game that has much natural inertia that is in play. Its obvious even skilled people here are sometimes frustrated. BUT, given quite low numbers of (brilliant) active users, the "documentation" solutions IMO fall into a funk-dump of nothing much happening. One needs MORE people to gain the traction needed IMO.

(3) -- I often wonder why there is no single page CRIB SHEET for the syntax with examples. But the truth is most of the "documentation" needed is there for use cases that arise daily spread over GG discussions. The problem is they disappear into the Google Swamp so people have to keep Re-creating The Wheel as great solutions are NEVER MARKED as such. We throw away learning resources at an astonishing rate.

(4) SO, in some ways I think your question is actually TWO different issues: (a) documentation of syntax; (b) simplification of syntax. Of course they are overlapping. But IMO we could be doing a lot better even now documenting the somewhat baroque methodology of TW. Part of it is about FLAGGING good solutions that necessarily instantiate good syntax examples. I suspect that might be EASILY DOABLE. All one would need is a list of links to GREAT POSTS with a description. I been considering doing it myself, but my skill level with computers is, realistically, too low to make such judgement calls.

Just thoughts
Best wishes
Josiah

[Thomas Elmiger]

Hi Tony,

Just a thougt on your search for (pseudo?) CONSTANTs: The most simple way would be to put the constant value in a tiddler of it’s own. If you wand to hide your constants, use a prefix starting with $: e.g. $:/constants/constant-name. This way, the value can be transcluded from anywhere (not sure how this relates to your term of sub-tiddlers):

{{$:/constants/constant-name}}

Have you allready considered this?

(As Jeremy says: Everything is a tiddler.)

All the best!
Thomas

PS: For the documentation aspect I would recommend to use separate existing threads like this one.

[Mark S.]

It's such a simple macro, I couldn't imagine what could go wrong unless we have different expectations for it's usage. Maybe you could post an example or export the tiddler and post here?

Comments --

The field "objecttabs" needs to already exist in the same tiddler where you are using <<editnsave>>.

You don't need to reload your browser when activating simple non-javascript macros. You only need to reload for plugins and javascript-based macros.

Good luck,
Mark

[TonyM]

Thanks Josiah for your considered response.

I will respond at greater length later (as it's bed time in Sydney) but thought I would say a free things. Tiddlywiki is powerful because of its structure and it's interrelated qualities and none should be lost. When I suggested these features be put into the core I should have elaborated. They need to be in the standard, at the top of the documentation. I have no doubt some smart coding can use existing structures to achieve what I ask and perhaps some plugins until then. I am as yet not knowledgeable enough to do this but I will be one day.

The ability to easily set reliable values from existing tiddler info text, tags and fields that is available in all related tiddlers with simple and deterministic ways (for somewhat novice users) is essential, along with a simple way to programmatically manage field values in the current tiddler is needed as well.

There is a caviate to this which will be in another reply from me tonight.

The problem I see is a gap in the early or middle ground and in ease of cognition without deep knowledge. My ability to understand this will fade as my expertise and expierence overcome the barriers I am facing. Something that is only possible because of a great community.

Thanks again
Tonym

[TonyM]

Thanks mark

I will revisit. I think I addressed everything including a reload to be sure. I expected it to work as well. I will share when I can get to it.

Tony

[TonyM]

Thanks Thomas,

It looks like I will need to use such a method but I need the constant(s) to be set from a value in an existing tiddler and maintained for that tiddler so some part of a tiddlers name will need to be in the path name to your suggested variable tiddler, then all tiddlers who would access that variable tiddler must know the same tiddler name.

I hope I make sense.

I am trying to avoid hard coded references so when a tiddler is copied or cloned it will behave the same in it's new name and inherit similar but a different set of values.

Thanks for the suggestion.

Tony m

[Thomas Elmiger]

Tony, that sounds like advanced requirements for programming ("similar" inheritance, wow!) that requires a concept, something like a data/structure model and documentation – not exactly stuff that should be covered by standard functionality or a beginner documentation ;–)

The more we know the more we can help, maybe starting with the concept. Maybe you could create an input form from where you create the main tiddler and the related constant tiddler (including the main tiddler’s name in the path).

Cheers, Thomas

2017-08-10 15:37 GMT+02:00 TonyM <anthony...@gmail.com>:

… I need the constant(s) to be set from a value in an existing tiddler and maintained for that tiddler so some part of a tiddlers name will need to be in the path name to your suggested variable tiddler, then all tiddlers who would access that variable tiddler must know the same tiddler name.

 

… when a tiddler is copied or cloned it will behave the same in it's new name and inherit similar but a different set of values.

[Danielo Rodríguez]

I'm still not understand why the set widget does not work for you. It sets a variable with certain name and that variable is accessible to all it's children . How is your requirement different ?

[TonyM]

A Quick description, I hope it helps

Psudo-Constants

TiddlerA has a title or field name

To set a constant you need to define a "variable" using the value of the tiddler title or field, however when you use any reference to the title or field it will be a string that refers to the field not the current value of the field. As a result it gets wikified in context and may refer to another tiddlers title or field depending on where it is used.

I have used two variable names and wikify to partially solve this. Quite cumbersome and it took time to find this solution. The ability to use the constant still seems limited.

\define currentobjectsrc() 

{{!!title}}

\end

<$wikify name="currentobject" text=<<currentobjectsrc>>>

I can now use the value in subtiddlers using <<currentobject>> but only where this is valid. It retains its value (in this case "the text "TiddlerA" in all subtiddlers, Can I use nested {{{}}} or something to make this work in macros and filters ? I am still trying to learn the different ways in the different widgets macros, template tiddler etc... Actually I know the answer to this it is documented at tiddlywiki.com however it is very contextual.

Perhaps there is a specific use of $set that is available to me, but I have not found it yet. It would be great if I could use a simple command like

<$set Constant=constantname value=((!!title}}>

Such the constantname now contains "TiddlerA" and can be accessed by various and consistent means in all subTiddlers (those called/Transcluded) by TiddlerA

To be clear I want to use {{!!title}} not {{TiddlerA!!title}} because I do not want to hard code "TiddlerA" into the TiddlerA tiddler because when cloned or copied it will have a new name or a different value in a field.

I have found many of the documented syntax or examples refer to "somename" rather than a name derived from a field, that does not change with tiddler or context.

I will try and publish into on my project soon, and perhaps there are other ways do achieve what I am doing. 

I am now in the process of memorising a "dozen" "substitution rules" to understand this.

Thanks For the help.

TonyM

[Mark S.]

It's better if you explain what it is that you want to accomplish than insist on how it gets accomplished.

The variable <<currentTiddler>> is available to all "children" of a tiddler, assuming that by children you mean transcluded or templated tiddlers. If you have some other interpretation of what children are, then you need to explain what you want to accomplish.

If you have a tiddler with several transclusions, and then clone that tiddler, all the transclusions of the clone will then use their <<currentTiddler>> value.

Good luck,
Mark

[TonyM]

Mark,

Sorry, but it is hard to explain what I want without reference to how to accomplish it when there are a lot of terms I am still becomming familular with.

Of course I did ask at the top of the post "Edit fields in Current Tiddler"

I have published a version of my work at https://tiddlywiki.psat.com.au use the table of contents to select applications and "application template" tiddlers. The Bottom of which "application template" has some attempts to use editnsave. Your replys suggest you do know what I need and Edit and save may be the answer. I would like edit and save to reference fields in the Application templaye (or its copies) and allow sub tiddlers (in tabs) to use it as well. All  Most tiddlers are tagged "Object Dev".

The Site itself is DRAFT only

I have actualy spent more time building the demo than reinvestigating the editnsave issue. But I have published to make it visible.

I will look into it further after I get some real work done :)

Regards
Tony

[Mark S.]

Ok. There's a couple things going on. One a mistake. One a semi-bug. And one probably a slight UTF8 cut and paste error.

In your application template, you forgot to close off <$wikify> with the closing </$wikify> tag. In addition, and I know this shouldn't really matter, but sometimes you need to stack your closing tags on top of each other instead of appending them to each other. That's a semi-bug IMHO. Anyway, your closing set of tags need to look like:

</$set>
</$set>
</$set>
</$wikify>

If they're not stacked like this, the formatting below doesn't work right. Probably someone can explain why, but it's a mystery to me.

Next, go to the "Edit and Save Field" tiddler and delete the existing $:/tags/Macro . There's something wrong with it. My guess is that you copied and pasted it from the forum, and it contains a hidden character. Type the $:/tags... again, and as you do the system should offer you $:/tags/Macro at the BOTTOM with the other system tiddlers. Select that $:/tags/Macro tag. ALSO, be sure to update the macro with the IMPROVED macro I provided (the one you have is the first draft).

After these changes, the formatting and macro should function well enough to ... be tweaked.

Have fun,
Mark

[Arlen Beiler]

Here is the documentation for the set widget http://tiddlywiki.com/#SetWidget

And you use it like 

<$set name="constantname" value=((!!field}}>

</$set>

Then all the child elements of the tag (think xml), will have that variable available to them. In a macro you can also use $(constantname)$ as a placeholder, and the value will be inserted as is before the macro is evaluated. I think it is a constant, meaning child elements can't change it, but it will be updated if the value source changes, I believe.

That's one thing you will discover about this group. We might not have it all together, but together we have it all. 

Enjoy!

-Arlen

--

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+unsubscribe@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/96b9dfe1-58f2-4dc3-9633-d6ac0d58812d%40googlegroups.com.

[TonyM]

Thanks Mark,

All working as advertised, it will be very helpful, thanks alot. Sometimes it seems like an art not a science :), You make me recall I learned to avoid cut and Paste from google groups in the Early TiddleyWiki Clasic days. Evan pasting into notepad on the way.

Thanks for working through it, what I have now will be invaluable.

Regards
Tony

[TonyM]

Thanks Arlen

I will revisit that because I had eliminated is from the combinatorial complexity, possibly not realising the difference between  $(constantname)$ and <<constantname>>

Thanks
Tony

On Friday, August 11, 2017 at 9:10:03 PM UTC+10, Arlen Beiler wrote:

Here is the documentation for the set widget http://tiddlywiki.com/#SetWidget

And you use it like 

<$set name="constantname" value=((!!field}}>

</$set>

Then all the child elements of the tag (think xml), will have that variable available to them. In a macro you can also use

\define editnsave(field)
<$vars tid="$:/temp/$(currentTiddler)$" fld="$:/temp/$(currentTiddler)$!!$field$" fldx="{{$:/temp/$(currentTiddler)$!!$field$}}" >

$field$: <$edit-text tiddler=<<tid>> field="$field$" default={{!!$field$}}  tag="input"/>

<$button>Save<$wikify name=val text="<<fldx>>"><$action-setfield  $field="$field$" $value=<<val>> /></$wikify>
</$button>

</$vars>
\end

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

[TonyM]

Areln,

Confirmed working, with the placement of the </set> like Marks </wikify> at the end of the tiddler with all calls to subtiddlers in the "content" of the set statement.

Regards
Tony