TW development best practices question

[Dave]

I have a project I'm thinking of starting in TW5 having made some progress in the past with TWclassic, but I think most of the cool developement is happening now and in the future with TW5.

So I'll be kind of starting from scratch. I have a best practices question:

<<
(having decided that I'll be using TW5 with nodejs) Would it be better to make one TW per client and import any design changes from a "master" TW file (that was the plan with the TWc version), or would it be better to have one single TW5 (synced between computers) and access the multiple client "files" by unique tag in the one system? And if that were the case would it be better to develop it in tiddyweb (accessible only through intranet)?<<

Here's the use case: I'm a chiropractor seeing multiple patients a day, keeping track of various symptoms and test results that change gradually over time and depending on progress generates the need for various modifications of treatment modalities, e.g. exercises, etc, as well as running suggested prioritized diagnosis suggestion lists and plans of management options.

Although it would be nice and tidy to have one file per patient, I also at one point in the future want to be able to compare findings between patients, like for research (how many patients that I treated by method X got better by Y points over timespan Z; or, what's the average first measurement of neck range of motion between age 30 and 50?)), mainly using fields and tags.

Any time I describe what I want, most people just say I should build a database program, but a) I have no experience with them and b) I just really like tiddlywiki because its so flexible.

Lastly, I'm an intermediate level user with no formal computer programming training, slow but steady learner. I've modified plugins (TW classic) but never made one from scratch.

Any suggestions for a scenario like this?

Oh, one last thing... if I ever actually achieve what I'm dreaming of, what are the monetization implications given the current licence? Could I sell this to other chiropractors/ companies? If not, that's fine - I'm going to proceed anyway and may just eventually just release it if it passes muster.

[Andreas Hahn]

Hi Dave,

I have not done larger projects in TW myself so far, but here are a few
things to give you an idea of what might be a good start.

TW with nodejs works by having a nodejs server in the background which
delivers a fully funtioning TiddlyWiki to the browser which then has its
contents synced with the server. The current process however is unsafe
for more than 1 concurrent user, so either way, unless you make the
necessary changes, your system will only be safe for 1 concurrent user.
By that I mean the nodejs-version and a TW that is synced between computers.

If you create a separate TW for each of your clients as a file, then you
will not have this issue, as now people can edit different client files
without interfering, as long as they edit different clients. That
however, as you pointed out, means that the data will also be separate
and it will be harder to aggregate. So be aware of the limitations to
the number of concurrent users your system can handle.

I would however use one single TW instance for all the data, because TW
really only shines, when you put all the data into it (much like
evernote). The nodejs version is pretty fine for a single user, as it
also means that the data will be kept in individual files that are more
likely to be accessible and compatible by other programs you might use
to work with that data. It also means that it won't be as portable as a
single TW file.

When it comes to your actual application, I can only advise you to keep
your data consistent. By that I mean well defined field names with well
defined definitions as to what data type they contain. TW is actually a
database application in that sense, but one that doesn't enforce that
type of consistency by default. You need to have a consistent model if
you want to work with the data later on. (so make sure there are no
ambiguous inputs or things you have to do manually everytime, like
typing out a specific tag, a specific field name and so on)

When it comes to selling, TW is under a BSD license, which as far as I
know does permit you to sell the final product.
I realize my answer was very broad, if you have any more questions, I
will be happy to address them in a little more depth.

/Andreas

[Dave]

Thank you for that! Does that mean if I want to eventually have concurrent access and widespread access to all patient data I should seriously consider tiddlyweb?

[Andreas Hahn]

Am 27.09.2015 um 19:42 schrieb Dave:
> Thank you for that! Does that mean if I want to eventually have concurrent access and widespread access to all patient data I should seriously consider tiddlyweb?
>

It does mean that by the time you are getting to that, you can only hope
that there is a good solution to that problem by then or implement it
yourself, as (afaik) tiddlyweb also does not work as an environment for
multi-user access. There are people working on that and nmaking progress
in that area, so that overall it is nearly working.

/Andreas

[Tobias Beer]

Hi Dave,

> one TW per client or have one single TW5

I would definitely try and do the former while establishing what you call a master for all the shared resources. It's pretty much what I am trying to do right now, anyway, see this post.

Later on, you could create one big TW from all the projects, assuming you have no naming conflicts. (Come to think of it, it would be real nifty to be able to merge tiddlers from different "editions" in one, in your case "projects", and then access or switch the alternative versions of tiddlers of the same name in some way... something that used to be different "stores" in TW2.)

Best wishes,

— tb

[PMario]

Hi Dave,

Interesting use case.

On Sunday, September 27, 2015 at 4:42:25 PM UTC+2, Dave wrote:

(having decided that I'll be using TW5 with nodejs) Would it be better to make one TW per client and import any design changes from a "master" TW file (that was the plan with the TWc version), or would it be better to have one single TW5 (synced between computers) and access the multiple client "files" by unique tag in the one system?

I think your usecase can be achieved, with some clever designed tiddlywiki.info files. ...
eg:
 - You can create a so called TW edition per patient.
 - This edition can include the basic layout + eventual modifications from a UI-master edition.

The tiddlywiki.info file supports an option: includeWikis

see: https://github.com/Jermolene/TiddlyWiki5/blob/master/editions/de-DE/tiddlywiki.info#L18 ...
 - I'm using it for the German translation editions. Where de-AT contains most of the content and de-DE only contains the differences.
 - In your case the "UI-master" can contain your layout changes and the patient edition contains the individual content tiddlers.
 - If you need some information, that should be global for every patients eg: a collection of useful exercises, you could include a second edition, that contains them. So you only need to edit / add new exercises once in eg: exercises-master.

 

 And if that were the case would it be better to develop it in tiddyweb (accessible only through intranet)?

TiddlyWeb would be a possibility, if you know hot to work with the python programming language. At the moment there is no easy way to work with tiddlyweb and TW5.
 

Here's the use case: I'm a chiropractor seeing multiple patients a day, keeping track of various symptoms and test results that change gradually over time and depending on progress generates the need for various modifications of treatment modalities, e.g. exercises, etc, as well as running suggested prioritized diagnosis suggestion lists and plans of management options.

As I wrote. One edition per patient.
 

Although it would be nice and tidy to have one file per patient, I also at one point in the future want to be able to compare findings between patients, like for research (how many patients that I treated by method X got better by Y points over timespan Z; or, what's the average first measurement of neck range of motion between age 30 and 50?)), mainly using fields and tags.

As Andreas wrote, having a good concept for tag and field names at the beginning, will help you in the future.

With the above mentioned tiddlywiki.info file, it would be possible to create a "big" edition, that "includes" all patients. You only need to take care, that there are no "naming problems". Eg if there are 2 tiddlers named "Mario", that last one, that is included will win.

 

Any time I describe what I want, most people just say I should build a database program, but a) I have no experience with them and b) I just really like tiddlywiki because its so flexible.

Lastly, I'm an intermediate level user with no formal computer programming training, slow but steady learner. I've modified plugins (TW classic) but never made one from scratch.

You are right. "Feeding" a database with all the info is an option, but you will need to create a UI. ...

With TW you get an advanced UI and very powerful tagging options and "list-widgets" to create different overviews. ... So imo it depends on your own preferences. ..
 

Any suggestions for a scenario like this?

Oh, one last thing... if I ever actually achieve what I'm dreaming of, what are the monetization implications given the current licence?  Could I sell this to other chiropractors/ companies?  If not, that's fine - I'm going to proceed anyway and may just eventually just release it if it passes muster.

As Andreas wrote. TW is BSD licensed. that lets you sell your modifications.

Conclusion:

IMO a basic "single user" application, for your own use case, should be relatively straight forward.

 - It is possible to start several servers at the same time.
   - You just need to take care, that you don't insert content into the "wrong" user page, if you opened several of them at the same time!

 - You'll need to start a new nodejs server if you want to access a new user.
   - This can be a disadvantage, since such servers need to be started from the command line.
   - Depending on your operating system, starting new users can be automated.

Question: Which OS do you use?

have fun!
mario

[Tobias Beer]

Hi Mario,

With the above mentioned tiddlywiki.info file, it would be possible to create a "big" edition, that "includes" all patients. You only need to take care, that there are no "naming problems". Eg if there are 2 tiddlers named "Mario", that last one, that is included will win.

I know it sounds like an enormous stretch, I couldn't help – before falling asleep yesterday – but to try and refactor the idea of allowing TiddlyWiki to load a number of editions (stores) into one wiki while gracefully handling multiple instances of tiddlers with the same name. Eventually, I just fell asleep. ^_^

~

Dave, perhaps it is indeed be best for you to use one big wiki for now, so long as the amount of data is reasonably manageable, to avoid any name-clashes later. When needed, you can extract / export any parts of it whenever you feel like you need a certain "client edition".

Best wishes,

– tb

[BJ]

Hi Dave,
what system you need depends on how much data you will have (is it just text?, how many patients), how it is to be updated (do different people need to update the data, are there emails ) and how it is kept secure (encryption, backups, will to be viewed in the browser).

kind regards
BJ

[Dave]

Which OS?

I'm using Linux

It'll mainly be text in tiny chunks like [ tiddler:RightCervicalRotation, fieldname:2015-09-28.11:40:19 AM, field content: 47 ] amalgamated into lists and summary tiddlers, but probably hundreds of them per visit, and over a patient's lifetime they can have up to hundreds of visits.  It will be mainly me updating the data, but if I ever get it good enough to distribute to other docs, there are often multiple people accessing it in bigger clinics, although not usually at the same time.  Id imagine you could keep it all behind a firewall of some sort, backups like any other file structure I suppose.

What I'm gathering is that Node.js is the way to go and mainly I have to decide whether to have it in different wikis or one big wiki.  Isn't the main point (or one of them) of TW using Node.js that size is irrelevant?  Or would a single TW with thousands of patients each with thousands of tiddlers become unwieldy even with node.js?

Also, lets say that was the case and I chose to go with individual wikis:  would it be easier to just grep information (I know bash better than javascript, ha ha) for multi-patient reports, or is it conceivable to have a separate "Admin" wiki that, although slower, would be able to include the whole mass of them (that would be preferrable).  I'm pretty sure that is what some of you have said or at least implied.

Also, isn't there a way to variably load subsets (patients) of tiddlers into the single TW, and just "purge and reload" the next one when needed, so it would behave like single multiple wikis, but it would still be just the one.  Is that what you were getting at Mario when you mentioned tiddlywiki.info files?  That way if you wanted to look at all patients with a certain diagnosis or demographic profile you could load just them...

anyway, thanks for all of your input!

-Dave

[Erwan]

Hi Dave,

Sorry I haven't followed exactly what you need, but you got my attention when you mentioned that you know Bash better than Javascript ;)

If using external scripts to manage your wikis is an option that you would consider for your workflow, in my opinion this is what gives you the most flexibility: you can convert back and forth between node.js and standalone html wikis, do any kind of batch processing with the .tid files, aggregate multiple wikis into one or split a big wiki into subwikis, use cron to perform automatic tasks, etc. The only disadvantage is that it's done offline, i.e. you can't have a script doing something with your wiki and you working on it at the same time.

I use Bash scripts for the CommunitySearch wiki, if you are interested in some examples: https://github.com/erwanm/tw-aggregator. Actually, the process that the aggregator does might share some similarities with your use case: typically if you want to generate a "meta-wiki" on some aspect of your data only once in a while (that is, you don't need the "meta-wiki" to be always synchronized), you could "aggregate" all the relevant tiddlers from the relevant wikis with a Bash script that you call only when you need it.

Hope this helps!
Erwan

--
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 post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/bacb94f5-83ca-4f7b-8470-bb4f96f1a31e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Erwan]

Hi Tobias,

On 28/09/15 06:48, Tobias Beer wrote:
> I know it sounds like a stretch, but I couldn't help but before
> falling asleep yesterday try and refactor aspirations for allowing
> TiddlyWiki to load a number of editions into one wiki while handling
> multiple instances of tiddlers with the same name gracefully.

> Eventually, I just fell asleep. ^_^

In the CommunitySearch wiki this is done simply by renaming any tiddler
X from wiki Y as $:/Y/X. The original title and source wiki are also
stored as fields to speed up filtering, which means that actually the
tiddler could be given any unique name. Then it would be fairly easy to
generate a tiddler X in the resulting wiki which would contain a
drop-down list from which the user can select which edition (source
wiki) they want to see.
But of course this option requires calling an external script, so some
might say it's like cheating ;)

Cheers
Erwan

[Tobias Beer]

Hi Dave,

 

What I'm gathering is that Node.js is the way to go and mainly I have to decide whether to have it in different wikis or one big wiki.  Isn't the main point (or one of them) of TW using Node.js that size is irrelevant?  Or would a single TW with thousands of patients each with thousands of tiddlers become unwieldy even with node.js?

I'm inclined to believe your anticipations are wee bit exaggerated. :D

Maybe not, and eventually you will have a million

patient related snippets flying about over time.

At that load, if something might bend over backwards,

it will probably be the standalone version.

With node you can start with one of those and later on,

if things should become unmanageable you can render

your patient data into more fine-grained wikis, if only alphabetically.

I would probably have a "patients" folder in my structure and,

in anticipation of your above amounts

one subfolder per letter in the alphabet.

Also, lets say that was the case and I chose to go with individual wikis:  would it be easier to just grep information (I know bash better than javascript, ha ha) for multi-patient reports, or is it conceivable to have a separate "Admin" wiki that, although slower, would be able to include the whole mass of them (that would be preferrable).  I'm pretty sure that is what some of you have said or at least implied.

It really depends on the complexity of what

you want to achieve with your aggregations.

I'm sure you'll come around with questions

once you hit a dead end on that.

Also, isn't there a way to variably load subsets (patients) of tiddlers into the single TW, and just "purge and reload" the next one when needed, so it would behave like single multiple wikis, but it would still be just the one.  Is that what you were getting at Mario when you mentioned tiddlywiki.info files? That way if you wanted to look at all patients with a certain diagnosis or demographic profile you could load just them...

 

You can basically "build" your wiki anyway you want in node,

you're not bound to have an all-or-nothing wiki.

In fact, your served wiki is an on-the fly view

of whatever you told the server to serve from the tiddler store.

Best wishes,

— tb

[Tobias Beer]

Hi Erwan,

 

In the CommunitySearch wiki this is done simply by renaming any tiddler
X from wiki Y as $:/Y/X.

Thanks for the input ...I was aware of that. :-)

The ultimate goal with my above day-dreaming exercise

would be for all internal linking as well as tagging, etc.. to eventually

aggregate the data into one big network,

rather than break the whole as well as each subnetwork (aka edition),

more or less, since everything got renamed.

 

But of course this option requires calling an external script, so some
might say it's like cheating ;)

So, it's not only cheating but rather has,

in fact, severe limitations.

You might well be the first for TW5

to try and remove some of them,

if you ever decided to try and do that.

I think it would be cool if your search results list

could show some popup when hovering a link,

context-search-highlighting the search term.
Or the whole lot being expandable by some button,

not rendered output, but only a source extract.

Best wishes,

— tb

[PMario]

On Monday,  September 28, 2015 at 8:08:44 PM UTC+2, Dave wrote:

Which OS?

I'm using Linux

ok
 

It'll mainly be text in tiny chunks like [ tiddler:RightCervicalRotation, fieldname:2015-09-28.11:40:19 AM, field content: 47 ] amalgamated into lists and summary tiddlers,

The structure you describe here can't be built with tiddlers. I'm pretty sure, that RightCervicalRotation is a term, that needs to be used several times. But tiddler names have to be unique and field names need to be without "special characters, spaces and the must be all lower case"

So you can have a tiddler eg:

title: <patient-id> - 2015-09-28.11:40:19 AM
right-cervical-rotation: 47
any-other-field: asdf

some descriptive content

pros:

If <patient-id> is unique, you'll have (allmost) no problems with duplicate tiddler names. (see cons)
It would be possible to mix different patients data, without naming conflicts.
These tiddlers are also anonymous, if the patient-id is not added to the data set.

cons:
With this configuration you can create 1 tiddler per second. Which is fine for a single user environment, but won't work for multiple concurrent users.

but probably hundreds of them per visit, and over a patient's lifetime they can have up to hundreds of visits.

So for a single user you'll easily have 10'000 elements. ... Since all TW data is loaded into the browser memory, you'll definitely hit the boundaries, where a single file TW is nicely usable.
 

 It will be mainly me updating the data, but if I ever get it good enough to distribute to other docs, there are often multiple people accessing it in bigger clinics, although not usually at the same time.

The very basic system, that I did describe in my first post, will work well for a single user. ... But it doesn't scale very well. If you need multi concurrent users, you'll definitely need a much more sophisticated concept and a server side backend. The TiddlyWeb concept should work quite well here.
 

 Id imagine you could keep it all behind a firewall of some sort, backups like any other file structure I suppose.

A firewall won't help here. The existing nodejs server is a very basic implementation for testing and sending single file TiddlyWikis. There is no server side indexing going on. The nodejs server dynamically builds a single file TW and sends it to the brwoser. So you won't gain any speed advantages with node.
 

What I'm gathering is that Node.js is the way to go and mainly I have to decide whether to have it in different wikis or one big wiki.  Isn't the main point (or one of them) of TW using Node.js that size is irrelevant?

No. If you load an "all tiddlers TW" it will build a really big single file TW and send it to the browser. There is absolutely no database like functionality at the moment. It's a testserver!
 

 Or would a single TW with thousands of patients each with thousands of tiddlers become unwieldy even with node.js?

Exactly!
 

Also, lets say that was the case and I chose to go with individual wikis:  would it be easier to just grep information (I know bash better than javascript, ha ha) for multi-patient reports, or is it conceivable to have a separate "Admin" wiki that, although slower, would be able to include the whole mass of them (that would be preferrable).  I'm pretty sure that is what some of you have said or at least implied.

:) If you grep the whole dataset and build a new but smaller set, you basically create an index TW. Indexing is a mechanism, where real databases shine, if compared to sequential harddisk IO access.
So imo you can start with a simple file based version, because it has much less "moving parts". But for you "end goal" you'll definitely need a real database with several indexes for fast access.

TiddlyWeb has a concept, to deal with "stripped down" data sets. It's called recipes.
 

Also, isn't there a way to variably load subsets (patients) of tiddlers into the single TW,

Yes, you can build your "grep filters" at the beginning, to keep the number of "moving parts" low. The current nodejs server has no idea about recipes, bags, multi user access. Also authentication and more importantly authorisation handling is completely missing.
 

and just "purge and reload" the next one when needed, so it would behave like single multiple wikis, but it would still be just the one.  Is that what you were getting at Mario when you mentioned tiddlywiki.info files?

Kind of. With the tiddlywiki.inifo files you can describe, how a TW should be built. So every patient can have one "edition". But you also can create an edition, that combines tiddlers from several patients, without duplicating the tiddler files. ... You just need to take care about naming conflicts. See my info above.
 

 That way if you wanted to look at all patients with a certain diagnosis or demographic profile you could load just them...

but only if you did your indexing. The nodejs server doesn't have such functionality at the moment.

have fun!
mario

[Tobias Beer]

@ Mario,

 

The very basic system, that I did describe in my first post, will work well for a single user. ... But it doesn't scale very well. If you need multi concurrent users, you'll definitely need a much more sophisticated concept and a server side backend. The TiddlyWeb concept should work quite well here.

I think he's a chiropractor, not running a chiropractical school.
So far, I did not hear Dave speak one word of multi-user.

So imo you can start with a simple file based version, because it has much less "moving parts". But for you "end goal" you'll definitely need a real database with several indexes for fast access.

What's wrong with a filesystem and using grep?

Also authentication and more importantly authorisation handling is completely missing.

When someone speaks of grep,

that wouldn't be the first thing to come to my mind. 

That way if you wanted to look at all patients with a certain diagnosis or demographic profile you could load just them...

  

But only if you did your indexing. The nodejs server doesn't have such functionality at the moment. 

That would indeed be something very powerful

when building / serving a TiddlyWiki from node,

I hope it will be something OS agnostic in the end.

Maybe we're back @ python and on a way TiddlyWeb5? :D

...possibly node can be bent to achieve the same.

~

@ Dave,
 

I'd imagine you could keep it all behind a firewall of some sort, backups like any other file structure I suppose.

So long as you build standalone output wikis for people to look at

and don't expoe your node-server outbound, there is no need for firewalls.

What I'm gathering is that Node.js is the way to go and mainly I have to decide whether to have it in different wikis or one big wiki.  Isn't the main point (or one of them) of TW using Node.js that size is irrelevant?

Yes,, size is irrelevant, so long as you know how to serve your tiddlers, i.e. in what "editions".
If you expect to have the server construct a wiki with 1.000.000 tiddlers and

then use and edit that wiki so as to write back changes to the server,

I suspect you'll have long before met Mr. Performance Barrier.

Best wishes,

— tb

[PMario]

On Tuesday, September 29, 2015 at 4:54:25 PM UTC+2, Tobias Beer wrote:

@ Mario,

 

The very basic system, that I did describe in my first post, will work well for a single user. ... But it doesn't scale very well. If you need multi concurrent users, you'll definitely need a much more sophisticated concept and a server side backend. The TiddlyWeb concept should work quite well here.

I think he's a chiropractor, not running a chiropractical school.
So far, I did not hear Dave speak one word of multi-user.

Hi did. In the first post he asked about selling a product. ..

... Could I sell this to other chiropractors/ companies?

see: companies.

see the following paragraph from Daves post:

It'll mainly be text in tiny chunks like [ tiddler:RightCervicalRotation, fieldname:2015-09-28.11:40:19 AM, field content: 47 ] amalgamated into lists and summary tiddlers, but probably hundreds of them per visit, and over a patient's lifetime they can have up to hundreds of visits.  It will be mainly me updating the data, but if I ever get it good enough to distribute to other docs, there are often multiple people accessing it in bigger clinics, although not usually at the same time.  Id imagine you could keep it all behind a firewall of some sort, backups like any other file structure I suppose.

-m

[PMario]

On Tuesday, September 29, 2015 at 4:54:25 PM UTC+2, Tobias Beer wrote:

So imo you can start with a simple file based version, because it has much less "moving parts". But for you "end goal" you'll definitely need a real database with several indexes for fast access.

What's wrong with a filesystem and using grep?

Nothing. As I wrote: "start with it". But dedicated indices are faster.
 

Also authentication and more importantly authorisation handling is completely missing.

When someone speaks of grep,

that wouldn't be the first thing to come to my mind. 

The part you quoted, is out of context. I was talking about the existing nodejs server implementation, which is missing authorisation.
 

That way if you wanted to look at all patients with a certain diagnosis or demographic profile you could load just them...

  

But only if you did your indexing. The nodejs server doesn't have such functionality at the moment. 

That would indeed be something very powerful

when building / serving a TiddlyWiki from node,

I hope it will be something OS agnostic in the end.

Yes. ... Much space for improvements :)
 

Maybe we're back @ python and on a way TiddlyWeb5? :D

...possibly node can be bent to achieve the same.

I did have a closer look to hapijs but nothing to share yet.
 

-m

[Tobias Beer]

Hi Mario,

 

I was talking about the existing nodejs server implementation, which is missing authorisation.

Yes, that is good to know.
Perhaps I'm assuming too much that people don't actually use it

for production servers over the www ...and then they do.

When Dave spoke of giving the data / wiki to someone else,

I didn't think he's talking of exposing any file-store or node server.

I'd be thinking of standalone wikis built for that purpose,

safely encapsulated, immutable, i.e. not writing anything back,

thus updated and maintained by Dave alone.

I did have a closer look to hapijs but nothing to share yet.

With "framework" possibly meaning anything,

I am a bit at loss trying to figure out what
hapi really is good for.

"Start your application like this" doesn't seem to be

the best introduction as to what something is for or good at.

Best wishes,

— tb

[Dave]

Thank you all for your information.  I think I'll re-read this whole thread a couple times before I dive into the project.

In your opinions, if I were ever to get it to the stage that it needs to be transformed from separate stand alone wikis to, say, tiddlyweb or tiddlybase (the future turn key tiddlywiki database ;), are there people in the community I could just hire to do the heavy lifting for me?  (I'm dreaming now)

[Erwan]

Hi Tobias,

On 29/09/15 05:57, Tobias Beer wrote:
> So, it's not only cheating but rather has,
> in fact, severe limitations.
>

It sure has, indeed, but it also has strengths that might be out of
reach in pure TW: I've come to realize that, in some use cases, if using
external scripts (made possible thanks to the node.js TW interface) can
fit the bill more easily than pure TW, why not? But I'm aware that this
might sound unorthodox to hardcore tiddlywikians ;)

> I think it would be cool if your search results list
> could show some popup when hovering a link,
> context-search-highlighting the search term.
> Or the whole lot being expandable by some button,
> not rendered output, but only a source extract.

Actually, one of the things I'd like to do is to make it easier for
people who have good ideas like you to implement them directly,
especially when it comes to the "interface" of the wiki (I mean things
which can be done by modifying only the "skeleton" wiki). At least it's
already possible to do a pull request, in case you are interested!
https://github.com/erwanm/tw-community-search
However I'm currently trying to work on the performance aspect and since
that might involve changing the way some things are represented, so it's
probably best to wait for that be done.

Erwan

[Jeremy Ruston]

Hi Erwan

> It sure has, indeed, but it also has strengths that might be out of reach in pure TW: I've come to realize that, in some use cases, if using external scripts (made possible thanks to the node.js TW interface) can fit the bill more easily than pure TW, why not? But I'm aware that this might sound unorthodox to hardcore tiddlywikians ;)

The standalone HTML configuration of TiddlyWiki is necessarily self-contained, but one of the goals of the Node.js configuration was to be able to tap into the world of tools for processing text files and making HTTP connections. It’s good that we can hack within TiddlyWiki but it’s important that we can hack connections between it and other things too.

Best wishes

Jeremy.