Copying fields in JS

[Arc Acorn]

I don't seem to have learned enough JS to really figure out where I should be looking to do this so I figured I'd ask. :D

!What I'm doing and Where I'm at:

Effectively I have replaced the normal machine title with a readable title in view mode.

In my editTemplate I added:

<div class='editor readableTitleeditor' macro='edit readabletitle'></div>

viewTemplate I added:

<div class='readableTitle' macro='view readabletitle'></div>

and used CSS to show the normal title as a sudo-tool-tip when hovering hovering over the readable title.

!!Why? 

So that I can use a single TiddlyWIki for multiple projects that I would like to keep track of and search at the same time and be able to overlap names by having the normal title + a readable title.

Example:

| Readable Title | Machine Title |

| Character Database | ChracterDatabaseBook1 | 

| Character Database | ChracterDatabaseBook2 | 

| Character Database | ChracterDatabaseBook3 | 

| Chapter 1 | C1Book1 | 

| Chapter 2 | C2Book1 | 

| Chapter 3 | C3Book1 | 

| Chapter 1 | C1Book2 | 

| Chapter 2 | C2Book2 | 

| Chapter 3 | C3Book2 | 

| Chapter 1 | C1Book3 | 

| Chapter 2 | C2Book3 | 

| Chapter 3 | C3Book3 | 

...etc 

----

Now that you know what I'm doing and why here's my question: 

How do I set the readable title to automatically copy the normal title if null?

[Arc Acorn]

Messing around a bit I think this could be done best by hijacking the "Story.prototype.saveTiddler" function, and using an if statement.

If readabletitle = "";

   readabletitle = newTitle;

But I'm really not sure how to go about adding such an if statement or if that's the right place. 

Given that I can't seem to get anything to stick. 

I tired simply adding:

tiddlerElem.setAttribute("readabletitle",newTitle);

To see if that would work since as far as I can tell that should always just overwrite the readabletitle field with the newTitle but that doesn't seem to be the case.
in firebug I can see that it adds the attribute but it doesn't populate the field nor save to the Tw file on save.

[PMario]

In TiddlyWiki the tiddler title is designed to be human readable.
Everything else will cause some trouble.

IMO this

<<newTiddler fields:"readabletitle:newTitle">>

should do the trick, if you use the "new tiddler" button to create a
tiddler.

If you did create your "machine" tiddlers with a program, it won't be
that easy.

----

I think it will be hard to modify story.saveTiddler.

I'd go with TiddlyWiki.prototype.saveTiddler -> store.saveTiddler.
These 2 functions are completely different.

I did have a closer look allready, but everything is very hacky at the
moment. So nothing to share. yet.

----

How did you create your "machine" tiddlers?

I do know, how your view template and edit template work and what you
want to do. I just don't understand the advantage of your usecase.

have fun!
-mario

[Arc Acorn]

From my testing I don't see how "<<newTiddler fields:"readabletitle:newTitle">>"  could for what I want.

It makes a new tiddler and makes the field but if I don't change the field to the actual tiddler title it just names itself "newTitle"

Which dose at least insure that there is a value, but I'm manly looking for a way to reduce copy/past action when I make a new tiddler where the machine name is also what the readable/display name is going to be.

As for:

"How did you create your "machine" tiddlers? 
I do know, how your view template and edit template work and what you 
want to do. I just don't understand the advantage of your usecase."

The advantages are very much vanity in how things are displayed however there are other uses as well: 

Example:

This is a screenshot of a mock book outline similar to what I actually use, as you'll notice very quickly this isn't really possible using the normal title system in Tw, however using Machine/Display pairs it's perfectly doable.

In order to make the same tree using only the unique Tw titles is messy and highly undesirable.

Outside of my own writing work however a Machine/Display title pair would also be of benefit to anyone who wants to use Tw as a CMS just as you use the same system in nearly any other CMS.

[PMario]

Hi,
I wanted to see if a plugin will fit your needs, or if you really need
to change the core. Hacking the core may have some unwanted side
effects, that may "bite" you in the future, if not done right. eg:
create incompatibility with 3rd party plugins.

I also wasn't sure about your workflow.

There are 3 possibilities which come to my mind at the moment.

1) create a new ToolbarCommand eg:"mySave"
2) hijack story.saveTiddler
3) hijack store.saveTiddler

ad 1)
create a new command, similar to config.commands.saveTiddler [1]. As
you found out allready, it will be needed to prepare the "edit DOM" so
story.saveTiddler can handle it.

pro:
* It's a stand alone plugin.
* There should be no compatibility issues.

cons:
* To get your "readabletitle" field, tiddlers have to be created using
the "edit mode"
* you'll need to find out, what DOM structure story.saveTiddler needs
to work as desired.

* I did test this possibility at the weekend. I turns out, to be
pretty unstable, since story.saveTiddler does the "overwrite existing
tiddlers" handling. To get it going in a user/dev friendly way, some
core changes would be needed, which imo won't happen.

-------------

ad 2)
modify story.saveTiddler() [2].
IMO there is no simple way to hijack this function. It'll probably end
up in a rewrite, which is errorprone. As you can see story.saveTiddler
calls "store.saveTiddler" [3] which has the needed parameters.

pros:
* none
cons:
* see ad 2)

-------------

ad 3)
modify store.saveTiddler() [4]
This function expects several params. (title, newTitle, ....
fields ... ). So it should be relatively easy to hijack it, modify the
fields object an call the original function, with all params. IMO the
code involved will be just a view lines.

pro:
* easy to hijack
* every tiddler will have the "readabletitle" field

cons:
* extensive testing needed, to ensure there are no incompatibilities
* every tiddler will have the "readabletitle" field

--------

A test snippet (If you copy the following 3 lines into FireBug or
DevTools console, a new tiddler will be created and saved.

var tid = new Tiddler("testxxx");
store.saveTiddler(tid);
saveChanges()

So if you want, that something like this creates a "readabletitle"
field, option 3) is needed.

--------------

you wrote:
>Outside of my own writing work however a Machine/Display title pair would
>also be of benefit to anyone who wants to use Tw as a CMS just as you use
>the same system in nearly any other CMS.

If the usecase should be more generic, I'd use a different, more
generic name instead of "readabletitle". For me it is similar to an
"alias". The problem is, there are some "aliasPlugins" out in the
wild. So it would be confusing to name it "alias". The second best fit
for me would be "label" or "tlable" for tiddler label.

I did an example extension [5] that should do, what you want. But I
used the name "label" for the custom field, since label can be
anything. It can be human readable, or a machine readable hash if
needed. IMO the usecase can be more generic this way.

__Be aware__
Using this verison will create a label field for every tiddler that
will be saved.

have fun!
mario
=================
If my answers and contributions are valuable, consider to help me, to
improve them. http://pmario.tiddlyspace.com/#Motivation
=================

[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Commands.js#L35
[2] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Story.js#L590
[3] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Story.js#L629
[4] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js#L340
[5] http://hoster.peermore.com/recipes/TeamWork/tiddlers.wiki#hijack-core-save-tiddler

[Tobias Beer]

Hi Arc,

Is it really required that you initially SET the readable title? Why not just hijack the function that reads the (title) field and, if a readable title is present, return that, otherwise return the normal core title?

Cheers, Tobias.

[Arc Acorn]

I like this approach! It seems far simpler and less error prone and it works very well with the tree plugin.

I am however having issues figuring out where I would put the needed if statement for the actual Tiddler display title though.

It seems like I could be able to add some inline JavaScript to the viewTemplate but inline JavaScript doesn't seem to work in the viewTemplate...? 

[Arc Acorn]

Some very good points... and through my own hackery over the last couple days it has lead me to believe that there isn't really any good/simple way to go about it in this manner, it seems to either cause unstably in Tw or violate browser security rules. 

However it dose seem like the radically simpler approach proposed by Tobias ie:"simply substitution of the normal title when the label == undefined" seems to be a safe bet as then only light modification of any needed plugins is needed to use the label over titles when available.

I would like to give you a personal Thank you! though for all the work you put into looking into this. looking through your example and ref I do feel like I know a bit more about the inner workings of TiddyWiki now, which should help me in the future figure out how hair brained an idea is before I bother the community. XD

[PMario]

On Monday, March 25, 2013 10:04:40 PM UTC+1, Arc Acorn wrote:

I would like to give you a personal Thank you! though for all the work you put into looking into this. looking through your example and ref I do feel like I know a bit more about the inner workings of TiddyWiki now, which should help me in the future figure out how hair brained an idea is before I bother the community. XD

You are welcome :)

Tobias and I did talk about a similar mechanism some days ago, so it was a nice exercise to dig a bit deeper into several possibilities. I also think I did find an edge case in the core, that isn't handled well but this needs some more investigation. So there are allways good points in asking questions.

Don't stop ... have fun!
mario

[Tobias Beer]

Hi Arc,

I started playing around a little but it needs some more fine-tuning...

https://groups.google.com/forum/?fromgroups=#!topic/tiddlywikidev/kA3wBiMYVQM

Cheers, Tobias.

[Tobias Beer]

While some feature I'd like to provide fails for now, you can check out..

http://tbtemp.tiddlyspace.com/#Foo

...and how it's title is displayed (also in the timeline).

Cheers, Tobias.

[Arc Acorn]

The good news it dose seem to work in allowing the titles to be changed with the CustomTitle.

The bad news: (On my system both an empty 2.7.1 and my main 2.7.0 + FireFox 22)

# I get a ton of (TypeError: parent is undefined) error messages. 

  * One when switching tiddlers tabs 

  * One when going into edit mode

  * Two when leaving edit mode
  * Three when opening a new tiddler 

  * A Dozen when refreshing with 4 tiddlers permalinked. 
  ...

# It seems to break quite a few plugins, more than I would like to try and list actually... 

# It also seems to break a couple of core functions: 

 * Tags no longer open popups
 * Anything after a TiddlyLink is not displayed:

[Tobias Beer]

Hi Arc,

Yes, I am aware of the problem. I actually have opened another thread hoping for some help. I could remove the functionality that would allow to use a tiddlyLink called [[Bar]] whereas Bar would not actually be a valid tiddler title but only a custom title for a tiddler called [[Foo]]... which is what breaks at the moment.

Give me a moment and I'll create a space for you with the basic version that does work.

Tobias.

[Tobias Beer]

Here you go...

http://customtitle.tiddlyspace.com

That's a minimalistic space with the desired functionality, with some more desirable stuff missing.

Cheers, Tobias.

[Arc Acorn]

Awesome Thanks! Now I have everything working pretty much just like I wanted it to!

One tiny Question on your todo's though:

For my proposes I set out to do this because I want a bunch of things to be named the same thing.

Wouldn't that cause a whole mess of issues if the system looks for the CustomTitle names in WikiLinking, and make the Timeline pretty hard to figure out if used there?

As a page display title and In the treeView plugin its amazingly awesome, but I could see some pretty big compatibly issues trying to use them in system that gains a lot of benefits from or are depended on being 100% unique.

P/s 

This is a little off topic but since it just hit me and is in the same vain:

I figure since you known a lot more about how things work and are the one that fixed up the treeView Plugin for me in the first place you would probably have a pretty good guess on this. 

Would it be possible to mod the treeView plugin to use a field to track sub nodes rather than tags?

ie: Making a field called treePlace: and than having comma separated names for each of the tiddlers it can be found under in the tree.

Well cool but could be a lot trickery would also be a "treeWeight" field so that way you could even organize tree items out side of the normal alphabetical order.

As is you get a lot of pretty bizarre and useless tags clogging up many tag lists and time to exclude them all as is. In the past I've thought about seeing about trying to hack some kind of dual tag system Machine|User but after looking around a bit decided it was just a pipe dream. However after this whole thing I'm kind of wondering if it's not possible simply use fields instead?

[Tobias Beer]

Hi Arc,

could you refresh my memory as to when/how I changed TreeViewPlugin for/with you? Can't remember.

I don't use it myself as I prefer editing tiddler-style lists in order to keep things simple and flexible. I had been working on a simple tree plugin a while back but as it is... things get buried.

Anyway, I just decided to publish a quick version of SimpleTreePlugin to get it out on the open...

http://simpletree.tiddlyspace.com

All it does is turn a list into an expandable tree and that's it.

What this does not and likely never will have...

• the ability to manage the tree other than editing a simple list
• i.e. no extra buttons to add or remove items
• cookie persistence of the tree state
  
• I believe using ListFiltrPlugin with a tree is far superior to trying to remember a tree state
• also, I would rather jump to the tree item that corresponds to the tiddler being just opened

That said, and considering all of...

https://github.com/tobibeer/TiddlyWikiPlugins/issues?page=1&sort=created&state=open

...while making TreeViewPlugin use fields instead of tags is entirely reasonable and possible,

I think I really need to pass on your request, sorry.

Cheers, Tobias.

[Arc Acorn]

"Could you refresh my memory as to when/how I changed TreeViewPlugin for/with you? Can't remember."

I can't quite remember what the forum post was called but here's the final link I have bookmarked:

http://pastebin.com/tifxw1JB

I can understand that for normal Tw use. 

For me my main (Most used) Tw is actually setup to be used as a multiple application replacement that acts as my main word processor, story management/general writing software, personal database, & journal.

Since I tend to treat it as a portable file system the tree view style is more intuitive to me.

Not to say that I don't also use a large number of lists as well. ^^; 

...while making TreeViewPlugin use fields instead of tags is entirely reasonable and possible,

I think I really need to pass on your request, sorry.

No problem gives me something to hack around with on the side when I don't feel like the normal writing.

Knowing that it should be possible is all I really wanted that way I know I'm not just wasting time tinkering with something that isn't possible. XP 

Though one thing that has me rather stumped me is this:

"MAS.getTiddlersPerTagAsHtmlList = function(tagname,setup)"

It seems to be where the plugin is getting the list of tiddlers that is processed to make the tree using tags. 

But I can't seem to find anything about "getTiddlersPerTagAsHtmlList" that would lead me to a custom field equivalent...

[Tobias Beer]

Hi Arc,

The entire magic for getting the right tiddlers is in this line...

tids = store.getTaggedTiddlers(tagname);

This tells the function getTiddlersPerTagAsHtmlLis to fetch the desired list as those tagged with a certain tagname.

Here is where you hook your custom function that likewise returns tiddler objects and perhaps could be...

//a new function of the TiddlyWiki class, i.e. the 'store' object

TiddlyWiki.prototype.parseBracketedList = function (title, field){

    //1. get the tiddler for the given title

    //2. retrieve the field value using store.getValue(title, fieldname)

    //3. turn the string value into an array using String.readBracketedList()

    //4. get tiddlers for each array entry using store.fetchTiddler(title)

    //5. add the tiddler to the return array

    //6. return what before was a string containing tiddler references as a list of tiddler objects

}

Then you could have a global variable for the plugin, like...

config.macros.treeview2.field = 'children';

If that is defined, it indicates that the user wants to rather use this field to define the relationship rather than tags, so getTiddlersPerTagAsHtmlList will eventually need some inner conditional like...

var field = config.macros.treeview2.field;

var tids = field ? parseBracketedList(tagname, field) : store.getTaggedTiddlers(tagname);

There may be additional places where you would have to use the field values instead of the tagnames as you likely also want those field values to be (easily) editable (add new ones, delete old ones) and also the sequence of elements in the bracketed list... much like you wanting to sort the tags of a tiddler.

In other words, adding a subitem to a 'folder' no longer happens by giving the item the folder as a tag, but instead by adding it to the children field at the corresponding parent.

An alternative method for modeling the relationship would be to use a parent field for each tiddler, instead of using a children field. From a sorting point of view, this seems to make things harder though. Additionally, if one wanted the same capabilities of polymorphism (the ability to have multiple parents) as a children field it should be a parents field ...regardless of whether biology tells us that humanoids may only have exactly two parents, one male and the other female.

Cheers, Tobias.