how to programmatically display a tiddler on startup?

60 views
Skip to first unread message

RA

unread,
Jan 11, 2008, 8:20:02 PM1/11/08
to TiddlyWiki
How can I do this:

On reload, check if any plugins are disabled, and if found, show a
WarningTiddler, followed by default tiddlers (DefaultTiddlers should
not have WarningTiddler added to it).

The reason I want the warning to be a tiddler (and not a message
dialog) is I'd like to put a bunch of controls there:
* a button to enable all plugins and reload
* a list of disabled plugins with toggleTag checkboxes for enabling
plugins selectively


Thanks.

RA.

Eric Shulman

unread,
Jan 11, 2008, 9:25:15 PM1/11/08
to TiddlyWiki


On Jan 11, 5:20 pm, RA <nameany...@gmail.com> wrote:
> How can I do this:
>
> On reload, check if any plugins are disabled, and if found, show a
> WarningTiddler, followed by default tiddlers (DefaultTiddlers should
> not have WarningTiddler added to it).

First, create a tiddler (e.g., [[SiteStartup]]) containing the
following script:
(requires http://www.TiddlyTools.com/#InlineJavascriptPlugin)
----------
<script>
var disabled=store.getTaggedTiddlers("systemConfigDisable");
if (disabled.length) story.displayTiddler(null,"WarningTiddler");
</script>
----------
Then, add this to the bottom of your [[PageTemplate]]:
<span macro="tiddler SiteStartup" style="display:none"></span>

When [[PageTemplate]] is processed at startup, [[SiteStartup]] is
rendered and the script it contains is automatically invoked,
triggering the conditional display of the [[WarningMessage]]. QED.

enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios

RA

unread,
Jan 11, 2008, 11:05:44 PM1/11/08
to TiddlyWiki
Thanks Eric,

I did exactly that already, but the WarningTiddler won't show up.
Could it have something to do with span display:none?

RA

On Jan 11, 6:25 pm, Eric Shulman <elsdes...@gmail.com> wrote:
> On Jan 11, 5:20 pm, RA <nameany...@gmail.com> wrote:
>
> > How can I do this:
>
> > On reload, check if any plugins are disabled, and if found, show a
> > WarningTiddler, followed by default tiddlers (DefaultTiddlers should
> > not have WarningTiddler added to it).
>
> First, create a tiddler (e.g., [[SiteStartup]]) containing the
> following script:
> (requireshttp://www.TiddlyTools.com/#InlineJavascriptPlugin)

Eric Shulman

unread,
Jan 11, 2008, 11:45:49 PM1/11/08
to TiddlyWiki
> I did exactly that already, but the WarningTiddler won't show up.
> Could it have something to do with span display:none?

are you by any chance using SinglePageModePlugin?

-e

RA

unread,
Jan 11, 2008, 11:57:00 PM1/11/08
to TiddlyWiki
> are you by any chance using SinglePageModePlugin?

Nope

RA.

RA

unread,
Jan 12, 2008, 1:55:52 AM1/12/08
to TiddlyWiki
> are you by any chance using SinglePageModePlugin?

Not using. Tried in an empty+InlineJavaScript. By adding an alert I
was able to see that the WarningTiddler gets rendered, but then
promptly disappears, replaced by default tiddlers.

if (disabled.length)
{alert(disabled[disabled.length-1].title);story.displayTiddler(null,"WarningTiddler");}

Eric Shulman

unread,
Jan 12, 2008, 2:47:52 AM1/12/08
to TiddlyWiki
> was able to see that the WarningTiddler gets rendered, but then
> promptly disappears, replaced by default tiddlers.

Aha! That makes sense... during startup, the TW core is simply
initializing the current 'story' before displaying any tiddlers...It
just isn't expecting something to have already opened a tiddler as a
*side-effect* of the PageTemplate rendering.

There may be an easy solution... try this:

<script>
var disabled=store.getTaggedTiddlers("systemConfigDisable");
if (disabled.length)
setTimeout('story.displayTiddler(null,"WarningTiddler")',1000);
</script>

The setTimeout("...",1000) adds a 1 second *asynchronous* delay to
give the normal startup rendering (including display of
DefaultTiddlers) a chance to finish *before* attempting to open
[[WarningTiddler]]

A 1 second timeout should be more than sufficient, but you may need to
tweak that delay for best results.

caveat: untested code... let me know if it works... or not...

-e

FND

unread,
Jan 12, 2008, 3:23:26 AM1/12/08
to Tiddl...@googlegroups.com
> Aha! That makes sense... during startup, the TW core is simply
> initializing the current 'story' before displaying any tiddlers...It
> just isn't expecting something to have already opened a tiddler as

Why not a simple plugin to hijack the restart() function:
---------------
restart_pluginControls = restart;
restart = function() {
restart_pluginControls.apply(this, arguments);
if(store.getTaggedTiddlers("systemConfigDisable").length > 0)
story.displayTiddler(null, "WarningTiddler");
};
---------------
This is untested, but it should work - unless I'm missing the point
here, of course...


-- F.

RA

unread,
Jan 12, 2008, 3:59:38 AM1/12/08
to TiddlyWiki
Both ways work, thanks!

Is "restart" less likely to occur than re-rendering of PageTemplate
(and thus invoking SiteStartup) or are they equal in that respect? I
mean in a typical TW usage scenario which one of the two gets invoked
more often? (hope I'm clear...)


RA.

FND

unread,
Jan 12, 2008, 5:05:59 AM1/12/08
to Tiddl...@googlegroups.com
> Is "restart" less likely to occur than re-rendering of PageTemplate
> (and thus invoking SiteStartup) or are they equal in that respect?

Restart is invoked once when the document is loaded, so this works just
like DefaultTiddlers. The script hidden in the PageTemplate is invoked
whenever the PageTemplate is refreshed, which occurs more frequently.


-- F.

Daniel Baird

unread,
Jan 12, 2008, 6:29:16 PM1/12/08
to Tiddl...@googlegroups.com
The other way to go is to add a "WarningTiddler" to DefaultTiddlers,
that contains a script to close itself if there aren't any disabled
plugins.

;D


--
Daniel Baird
They say a million monkeys typing will eventually produce Shakespeare.
Thanks to commenters on YouTube, we now know this is not true.

Eric Shulman

unread,
Jan 13, 2008, 10:33:13 AM1/13/08
to TiddlyWiki
> The other way to go is to add a "WarningTiddler" to DefaultTiddlers,
> that contains a script to close itself if there aren't any disabled
> plugins.

I like this idea! It avoids using either a "timeout" or a "hijack"...
both of which are good techniques, but seem a bit heavy-handed for
this particular use-case.

However... having a tiddler that automatically closes itself can be
problematic. To wit:

Unless there actually ARE disabled plugins, any attempt to open
[[WarningTiddler]] will immediately close it, making it practically
impossible (or at least VERY difficult) to view/edit the content of
that tiddler!!

One way to work around this it to put
if (!startingUp) return;
at the beginning of the embedded inline script, as in:
<script>
if (!startingUp) return;
var disabled=store.getTaggedTiddlers("systemConfigDisable");
if (!disabled.length) story.closeTiddler("WarningTiddler");
</script>

The "startingUp" variable is set by the TW core, and is TRUE only
during the core's initial loading sequence, including displaying the
DefaultTiddlers. By checking this flag, [[WarningTiddler]] can
automatically close itself during the startup sequence (if there are
no disabled tiddlers), but won't do so if you subsequently attempt to
view/edit the content in [[WarningTiddler]] after startup has
completed and 'startingUp' is set to FALSE.

HTH,

FND

unread,
Jan 13, 2008, 10:54:47 AM1/13/08
to Tiddl...@googlegroups.com
>> The other way to go is to add a "WarningTiddler" to DefaultTiddlers,
>> that contains a script to close itself if there aren't any disabled
>> plugins.
>
> I like this idea! It avoids using either a "timeout" or a "hijack"...

I agree, and I like Eric's script.
My only concern is that it *might* cause an initial flicker, i.e. the
user might witness the WarningTiddler being rendered and closed.


-- F.

RA

unread,
Jan 13, 2008, 11:06:08 AM1/13/08
to TiddlyWiki
> My only concern is that it *might* cause an initial flicker, i.e. the
> user might witness the WarningTiddler being rendered and closed.

My bigger concern is keeping this self-closing tiddler in
DefaultTiddlers at all times. But that wouldn't be too hard to arrange
by modifying Eric's "set default tiddlers" script that I'm using.

FND

unread,
Jan 13, 2008, 11:38:19 AM1/13/08
to Tiddl...@googlegroups.com
> My bigger concern is keeping this self-closing tiddler in
> DefaultTiddlers at all times. But that wouldn't be too hard to arrange
> by modifying Eric's "set default tiddlers" script that I'm using.

Just for future reference, the code will probably look something like this:
---------------
var tiddler = store.getTiddler("DefaultTiddlers");
if(tiddler)
tiddler.text = "WarningTiddler " + t.text;
else
config.shadowTiddlers["DefaultTiddlers"] = "WarningTiddler "
+ config.shadowTiddlers["DefaultTiddlers"];
---------------

HTH.


-- F.

Eric Shulman

unread,
Jan 13, 2008, 12:45:13 PM1/13/08
to TiddlyWiki
> tiddler.text = "WarningTiddler " + t.text;

If an existing [[DefaultTiddlers]] already contains either
'WarningTiddler' OR '[[WarningTiddler]]', this will add a redundant
entry to the list. While this doesn't result in two copies of the
tiddler being displayed, it DOES cause the tiddler to be rendered
twice during startup... and if that rendering triggers any side-
effects, then it could be a problem.

Here's a little 'fixup' that will remove any existing references to
WarningTiddler before adding it:

tiddler.text = "WarningTiddler "+t.text.replace(/(\[\[)?
WarningTiddler(\]\])?/,"");

Note: assigning directly to the "tiddler.text" property of a retrieved
tiddler object *can* be tricky:

Normally, the TW core functions, store.saveTiddler(...) or
tiddler.set(...) (for low-level internal operations) are used to
change the value in the tiddler data, and these functions trigger side-
effect processing, such as refreshing the display or even auto-saving
the file in response to changes in tiddler content.

In addition, lots of plugins hijack these functions in order to add
system-level extensions that are triggered whenever a tiddler is
changed. Directly setting the value of "tiddler.text" completely
bypasses these functions, preventing all add-on AND core side-effects
behaviors from being triggered.

Even so, in this particular case, changing [[DefaultTiddlers]] early
on in the startup sequence is probably safe enough since the changed
value is only used once, towards the very end of the startup
processing, to show the initial tiddlers. However, this may not
always be so, depending upon what specific plugins are installed and
what kinds of features they provide.
Reply all
Reply to author
Forward
0 new messages