[TW5] Future Feature - Update Template

[TonyM]

Folks,

I am specifying something I plan to build into a TiddlyWiki Solution however I see value in incorporating it into the core, or a key plugin. 

As such I thought I would raise it here for feedback and consideration.

The idea would be to extend the current two tiddler modes View and Edit with a Third, and perhaps while we are at it allow additional ones to be defined.

I am specifically interested in one I could call updateTiddler in addition to editTiddler and ViewTiddler

To recap

ViewTiddler - Global generic non interactive view tiddler mode

EditTiddler - Global generic interactive edit tiddler mode that presents access to all possible tiddler tag and fields

Proposed

UpdateTiddler - Global generic interactive  tiddler mode that presents access to selected tiddler tag and fields optionally via other tools and macros.

and this update tiddler mode will allow selective display of update components according to tag, field and other settings.

Vision for updateTiddler views

This would provide a customisable view of tiddlers so that users need not need tiddlywiki edit and structure knowledge to start manipulating tiddlers. The designer will present the fields the user should be able to change in whatever what they see fit, while keeping the viewtemplate suitably generic. Update templates would most likely be where most the the view customisation will take place.

If this model was to be developed I would think another smart thing to do would be to create a tiddler edit priority model (For want of better wording). This priority could be only for UpdateTiddlers, but better yet apply to all modes.

I can give more details if there is an interest in the above, or the idea of setting different edit/delete modes for tiddlers is desirable to you.

Regards

Tony

[PMario]

On Saturday, April 28, 2018 at 3:56:46 AM UTC+2, TonyM wrote:

Proposed

UpdateTiddler - Global generic interactive  tiddler mode that presents access to selected tiddler tag and fields optionally via other tools and macros.

and this update tiddler mode will allow selective display of update components according to tag, field and other settings.

I personally would like use the tiddler "info area" for this.

just an idea.

-m

[Mat]

@TonyM, 

yes, but:

I think it makes sense to improve the editmode experience and I have some opinions on what should be done BUT I think the main problem is the very editor! I really wish we could have a more interactive editor that featured something comparable to Intellisense - word completion, hover over a widgetname to get e.g parameter list etc. This really would simplify editing. (It really doesn't make sense that we have to look up parameters etc in the docs all the time!)

(Of course, TidBitz is an attempt to even further save the user from having to go into edit view. Unfortunately dev there is stuck.)

Now, that said, I'm curious to hear more about your vision. Who exactly is the audience for the modified edit view? If the UpdateTiddler view is both designed by me and then intended to be used by me... then I'm not sure the benefits are worth the effort. Especially if the idea is that I make different such a customized edit modes for different applications (again with myself as end user).

Or is the idea to use it for multi-user-TWs? I could see value in that context... but multi-user-TWs are not quite established yet. I know only of Jeds late MultiUser creation which I hope will be useful but I've yet not had a context to use it in.

<:-)

[PMario]

On Saturday, April 28, 2018 at 11:59:43 AM UTC+2, Mat wrote:

I think it makes sense to improve the editmode experience and I have some opinions on what should be done BUT I think the main problem is the very editor! I really wish we could have a more interactive editor that featured something comparable to Intellisense - word completion, hover over a widgetname to get e.g parameter list etc. This really would simplify editing. (It really doesn't make sense that we have to look up parameters etc in the docs all the time!)

With 5.1.16 we did a complete revise of the codemirror editor. Including the "cm-autocomplete" addOn. ... It knows about CSS, HTML, XML, javascript, elements. Since those elements are part of cm. ...

There is an "anyword-hint" function, that uses the existing text to lookup new words. ...

We also made the whole configuration much easier, since importing an add on also auto-configures the plugin with sensible defaults. So _no_ messing around with a json tiddler anymore. Most settings are directly available in the ControlPanel. ...

I know, that's far away from "Intellisense", but the basics are there, we "just" would need some TW-wiki-text-hint creators :)

have fun!
mario

[Mat]

On Saturday, April 28, 2018 at 1:10:23 PM UTC+2, PMario wrote:

With 5.1.16 we did a complete revise of the codemirror editor. Including the "cm-autocomplete" addOn. ... It knows about CSS, HTML, XML, javascript, elements. Since those elements are part of cm. ...

FYI I just posted a question about this on the main board.

<:-)

 

[TonyM]

Mario,

By info Area I understand you mean under the Info Button, the drop down view.

I  some ways it would be nice to choose what view appears in a tiddlers view on opening a tiddler, the edit, update or view and then have the remaining ones available under the info button, or a new button like mode.

I am however keen to have an update view that I or a visitor sees that is about the tiddler. For example If I made a log tiddler it would be in an update view which displays the content of the text field towards the bottom with an edit field at the top where I can type a log entry and press a button to append it to the text. Many of the regular toolbar buttons would be hidden, the log tiddler in update view/mode will be just about  logging.

The tiddler in view mode it would present as normal with all the toolbar buttons including edit

The tiddler in edit mode it would present as normal with all the toolbar buttons including clone and new here etc.. On edit you would see all fields, the text field in its standard place and all the code mirror extensions.

In this way visitors or casual users including ourselves on returning to a tiddler designed for a particular function will simply get a tiddler that is about that function, not a generic tiddler that happens to be for that function.

Regards

Tony

[TonyM]

Mat,  Also see my reply to Mario.

 

I think it makes sense to improve the editmode experience and I have some opinions on what should be done BUT I think the main problem is the very editor! I really wish we could have a more interactive editor that featured something comparable to Intellisense - word completion, hover over a widgetname to get e.g parameter list etc. This really would simplify editing. (It really doesn't make sense that we have to look up parameters etc in the docs all the time!)

I think this is a very different problem to that I am trying to address, I support what you want, and being able to bring such technology to a text box as opposed to just editing tiddler would be great.

(Of course, TidBitz is an attempt to even further save the user from having to go into edit view. Unfortunately dev there is stuck.)

Mat, I am working on some solutions  that may support you in this effort. Perhaps we should consider a collaboration? Especially the issue "look up parameters etc".

Now, that said, I'm curious to hear more about your vision. Who exactly is the audience for the modified edit view? If the UpdateTiddler view is both designed by me and then intended to be used by me... then I'm not sure the benefits are worth the effort. Especially if the idea is that I make different such a customized edit modes for different applications (again with myself as end user).

The audience is anyone, Most importantly those without tiddlywiki knowledge, because there would be no need for them to even know what a tiddler is, how to edit them and what fields are. They will only see a refined presentation or interface to the tiddler as the designer intends. 

However even with a single user/designer it allows simplification, built for purpose tiddler based views, once you build something you just use it. I for one often find myself hitting edit on a tiddler I do not need to edit when I meant to select a tiddler listed by it, say work in progress tasks. Once you build a task list, it will look like a task list, not a tiddler functioning as a task list.

  

Or is the idea to use it for multi-user-TWs? I could see value in that context... but multi-user-TWs are not quite established yet. I know only of Jeds late MultiUser creation which I hope will be useful but I've yet not had a context to use it in.

<:-)

I believe such a solution would make tiddlywiki more versatile and more suitable to a casual user, so it will benefit both multi-access wikis and shared TiddlyWiki solutions. Ideally such solutions may be a "gateway drug" into tiddlywiki. We are often casual users of our own designs so it can help the sole designer/user as well.

I have being using Jeds multi-user which I would call multi-access and I am confident once I learn how to host it for other users (outside my LAN) however a compelling use is so you can open multiple instances and never overwrite yourself on the same desktop with multiple browser tabs and sessions. It allows you to "clone" tiddlywiki sessions without fear of overwrite.

Regards

Tony

[TonyM]

Mat,

On further thought if we could have an update view and this was extensible we could build a designer view where tidbiz actively builds the tiddler, once build however it can all be hidden in the other views.

I think your desired approach is achievable with the following functions.,

• A Special dropzone on tiddlers (perhaps only in a designer view) where dropping a snipit will create a field eg; display-1 display-2 fields. It would also be helpful if this could be reordered with drag and drop. 
• Then in view or update mode each of these are transcluded in order and rendered. These would be your reusable code eg; lookup tag, a text editor view a checkbox tool. They can just be macros if desired.

My own MyMenus plugin http://tiddlywiki.psat.com.au/mymenus/has menu items that work in a similar way to above. What I have discovered is these snipits are like your code moduals and the traditional snipit so I am building a library of them. I will eventually also add an Editor toolbar button that allows you to search only snipits and insert them  in the text field. Also working to allow field management such that should you create a menu-fieldname you can select its value from a dropdown of all other menu items/snipits.

Regards

Tony

[TonyM]

Folks,

I have build but not published a solution for this. The idea is to maintain the idea of an Edit and View Template structure with sub templates such as the update template.

I now have the ability to make multiple alternate view/edit templates triggered by a fields existence.

A Summary of my actions

I have cloned and renamed $:/core/ui/ViewTemplate and $:/core/ui/ViewTemplate then updated 

$:/core/ui/PageTemplate/story to call the replacement $:/core/ui/ViewTemplate and $:/core/ui/ViewTemplate 

To provide a hook for this in future It would be nice to alter $:/core/ui/PageTemplate/story to allow parameters for View and Edit. See my PSaT Edit here

<$list filter="[list[$:/StoryList]]" history="$:/HistoryList" template="$:/PSaT/ViewTemplate" editTemplate="$:/PSaT/EditTemplate" storyview={{$:/view}} emptyMessage={{$:/config/EmptyStoryMessage}}/>

Now I have edited my $:/PSaT/ViewTemplate tiddler Snipit only

<$vars storyTiddler=<<currentTiddler>> tiddlerInfoState=<<qualify "$:/state/popup/tiddler-info">> userClass={{!!class}}><$tiddler tiddler=<<currentTiddler>>><div data-tiddler-title=<<currentTiddler>> data-tags={{!!tags}} class=<<frame-classes>>>

<$list filter="[all[current]has:field[update-mode]]" variable=nul>Update Mode On <$list filter="[all[shadows+tiddlers]tag[$:/tags/UpdateTemplate]!has[draft.of]]" variable="listItem"><$transclude tiddler=<<listItem>>/></$list></$list>

<$list filter="[all[current]!has:field[update-mode]]" variable=nul><$list filter="[all[shadows+tiddlers]tag[$:/tags/ViewTemplate]!has[draft.of]]" variable="listItem"><$transclude tiddler=<<listItem>>/></$list></$list>
</div>
</$tiddler></$vars>

Such that if the current tiddler has:field[update-mode] it will use items tagged tag[$:/tags/UpdateTemplate]

Without providing all the details I have replicated the TiddlerTool bar visibility options and created a custom $:/core/ui/ViewTemplate/title tiddler to ($:/PSaT/UpdateTemplate/title) to honour these settings. 

My New updateTemplate can now be independently tagged with tiddlers as an alternate to using the view template. So for example I simply add the field update-mode to a tiddler and uses the UpdateTemplate which hides the Edit Button behind more and displays selected edit fields below the tiddler text. I plan to provide a way to even remove the edit button from behind more, and have a global switch to overide UpdateTemplates with the ViewTemplate. Eventually I want the CustomView tiddlers to be drawn from a simple tag list.

The same model can be used for the EditTemplate such that you could have an additional edit mode that exposes for edit, only the fields you want. Perhaps an example called  EditTextOnly editTemplate.

I plan to build a Readonly-editmode view that can be locally or globally applied 

I am now plan to build a special set of sub ViewTemplates to allow the the toolbar and fields to be divided into headers, body and footer within a "Outliner" view. Where the alternate views are displayed within an outliner tiddler with each tiddler selected. This will also allow the readonly view to present in a readonly viewer

So to re-iterate, have only interfered with the core in $:/core/ui/PageTemplate/story

If this was parametised the default View and Edit Templates could be set in the control panel or system tiddlers to alternatives, perhaps provided in a plugin or bundle, and if compelling in the core.

In closing you see I have demonstrated the the technical solution, if you see my vision please help

• Minor Change to future core to facilitate and avoid core override, and provide settings.
• Produce the tool to define and replicate such alternate view and edit templates.
• Criticise and improve my techniques.

To me this opens TiddlyWiki to a more sophisticated interface where the complexity of tiddlywiki can be hidden globally or just inside a view tiddler. It would enable users a reduced learning curve when a solution or edition caters to there ignorance and does not demand they learn (Yet) key tiddlywiki concepts, they will simply experience the result.

Possible additional futures

• Perhaps we could even allow some view/edit templates to be encrypted so that other view/edit templates will be used instead until the encrypted ones are decrypted.
  
• Perhaps we could Provide an edit mode for the text field(s) that prohibits more than wikitext so there is no code insertion.

Regards

Tony