Thanks Arlen,
I keep your idea on the margin when I'll go deeper.
Quite familiar with async call though.
However is there any benefits to handle tiddlers that way rather than using
startup modules ?
Thanks
Le mercredi 21 août 2019 00:22:12 UTC+5:30, Arlen Beiler a écrit :
>
> To load tiddlers on startup you can use the preloadTiddlers array.
>
> 1. Put this code in a head script: $tw = { boot: { suppressBoot: true },
> preloadTiddlers: [] };
> 2. Query the server for the user's tiddlers and handle the response
> asyncly when it is recieved (good for performance).
> 3. Wait for the window load event, which indicates that all code is
> initialized.
> 4. Push the JSON tiddlers (as field hashmaps) to the preloadTiddlers
> array.
> 5. Call $tw.boot.boot();
>
> Tiddlywiki doesn't know the difference between this and a single-file
> wiki. It works the same in the browser once you call $tw.boot.boot();
>
> On Tue, Aug 20, 2019 at 10:34 AM Jeremy Ruston <[email protected]
> <javascript:>> wrote:
>
>> Hi Xavier
>>
>> If I understand correctly. The save button call a saver (are the savers
>> chained in case of multiple setup, eg gitub, gitlab...? ) while the
>> syncadaptor is dynamic and reacts to events ? If its correct I like the
>> mechanism as it gives users a way to easily backup their wikis.
>>
>>
>> That's correct. The other thing to bear in mind is that the saver
>> mechanism can also be used to export any data as a file, it's not
>> restricted to saving the wiki itself.
>>
>> I'm not sure to understand here. I think this is why I'm lost. While
>> studying the syncadaptor I didn't get any understanding about how the
>> remote stored wiki has been initialized in the first place and this is why
>> I was thinking about my described mechanism. Load a self contained wiki.
>> Setup the ipfs target and then use the syncadaptor to push the contents to
>> IPFS.
>>
>>
>> In the case of the standard client server configution, the browser
>> connects to the default route triggering a build of the entire wiki file:
>>
>>
>> https://github.com/Jermolene/TiddlyWiki5/blob/master/core/modules/server/routes/get-index.js
>>
>> Another alternative is to start with an empty index.html stored anywhere
>> accessible via HTTP and have it interrogate the server for tiddlers when it
>> starts up.
>>
>> I think this is where I'm going to start. Define a saver and save the
>> whole content. I was too ambitious to jump right away on a SyncAdaptor.
>> There is always a learning curve...
>>
>>
>> Indeed, the saver mechanism is conceptually much simpler. It's also
>> likely to perform better in many situations as one large HTTP transaction
>> is generally faster than lots of little ones.
>>
>> I was following my idea. All the syncadaptors I studied assume that the
>> content is already on a remote server and I didn't see how the content has
>> been built in the first place. You explained earlier the external build
>> process but I still don't understand how the first load is working. If I
>> follow your mind It means that let's say you offer your user to start from
>> a set of wiki templates. Those templates are already built by an external
>> process. I was thinking like described. Load a plain wiki, install the
>> plugin, setup the plugin then sync to IPFS. The property was meant to
>> detect whether or not this wiki is already synced. I was looking to some
>> index technics but I didn't figure out yet how to get and process the store
>> list.
>>
>>
>> The core client-server implementation uses etags to keep track of whether
>> a particular tiddler has changed.
>>
>> Not sure to understand what you mean by updated. I'm targeting a single
>> user model. The only updates should come from the user actions. (updated
>> tiddlers, removed tiddlers,etc...)
>>
>>
>> That will certainly simplify things.
>>
>> Many thanks for your great work.
>>
>> Warmly.
>>
>>
>> Thank you for your interest, IPFS is really very cool and I'm delighted
>> to see you experiment with it,
>>
>> Best wishes
>>
>> Jeremy
>>
>>
>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "TiddlyWikiDev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/tiddlywikidev/004560cd-7acf-4408-a3b2-63e049db291a%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/tiddlywikidev/004560cd-7acf-4408-a3b2-63e049db291a%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "TiddlyWikiDev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/tiddlywikidev/b59dab66-8c82-4739-acd2-cc2a714f5e5f%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/tiddlywikidev/b59dab66-8c82-4739-acd2-cc2a714f5e5f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "TiddlyWikiDev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/tiddlywikidev/65046341-255B-45EB-91BF-D4FB4F905892%40gmail.com
>>
>> <https://groups.google.com/d/msgid/tiddlywikidev/65046341-255B-45EB-91BF-D4FB4F905892%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/0635867c-aab3-4067-847a-62b4c3a6ea8b%40googlegroups.com.
