Ticket 160: Extend PrettyLinks to fall back to an external link if target is missing

[Saq Imtiaz]

http://trac.tiddlywiki.org/ticket/160

This was deferred in the interest of find a better syntax. Has anyone
had any thoughts? I find myself needing this very often... and since
it is usually in the case of links to plugin documentation a plugin
wont do as I cannot count on the user having it installed.

Cheers,
Saq

--
TiddlyThemes.com ( http://tiddlythemes.com ) : a gallery of TiddlyWiki themes.
TiddlySnip ( http://tiddlysnip.com ) : a firefox extension that turns
TiddlyWiki into a scrapbook!
LewcidTW ( http://tw.lewcid.org ) : a repository of extensions for TiddlyWiki

[Udo Borkowski]

My current approach to solve this issue:

(refering to the example in http://trac.tiddlywiki.org/ticket/160):

Just add a shadow tiddler named as the "deferred" tiddler:

config.shadowTiddlers.ForEachTiddlerDocumentation =
"See documentation [[online|http://tiddlywiki.abego-software.de/#ForEachTiddlerDocumentation]]";

This way users will get the link to the online tiddler if no "real" tiddler "ForEachTiddlerDocumentation" is included in the TW.

The approach works for all versions of TW..


Udo

----------
Udo Borkowski
http://www.abego-software.de

[Saq Imtiaz]

Hi Udo. I have been using this approach for sometime now as well but I
had really hoped I could avoid it in the future!

[FND]

> I have been using this approach for sometime now as well but I
> had really hoped I could avoid it in the future!

Saq just saved me from creating a new thread for this (note to self:
always check Trac before writing up a supposedly new suggestion... ).

I don't quite see what's wrong with the proposed syntax:
[[label|tiddler|URL]]
The only drawback is that a label/description would be required - which
is really not a big deal IMHO.

To avoid this, maybe the label parameter could simply be left blank:
[[|tiddler|URL]]
This would automatically use "tiddler" for the label (which might be a
good idea anyway).

-- F.

[Jeremy Ruston]

> > I have been using this approach for sometime now as well but I
> > had really hoped I could avoid it in the future!

I think Udo's approach does have some advantages, and is quite
elegantly TiddlyWiki-ish. The trouble with the proposed linking syntax
is that it has to be used everytime there's a reference to the tiddler
that is potentially missing. That means that if there were a lot of
references, updating them would be painful.

> I don't quite see what's wrong with the proposed syntax:
> [[label|tiddler|URL]]

After all this time, I'm not sure either, and my gnomic comment on the
ticket doesn't help! I think my reservations were actually with the
approach as a whole.

Cheers

Jeremy

> The only drawback is that a label/description would be required - which
> is really not a big deal IMHO.
>
> To avoid this, maybe the label parameter could simply be left blank:
> [[|tiddler|URL]]
> This would automatically use "tiddler" for the label (which might be a
> good idea anyway).
>
>
> -- F.
>
> >
>

--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com

[FND]

> I think Udo's approach does have some advantages, and is quite
> elegantly TiddlyWiki-ish.

Possibly, but it's also somewhat complicated, and it clogs the list of
shadow tiddlers if used extensively.
Also, that workaround is unsuitable for regular users.

> The trouble with the proposed linking syntax
> is that it has to be used everytime there's a reference to the tiddler
> that is potentially missing. That means that if there were a lot of
> references, updating them would be painful.

That's a good point - though I'm not sure whether it's a deal breaker;
after all, regular tiddler links are not updated either when the
respective tiddler is renamed.
The way I see it, we'd rather have this feature implemented with that
tiny flaw than not having it at all...

... except if it would lead to bloat or decreased performance, but the
respective patch/changeset looks quite harmless.

-- F.

[Jeremy Ruston]

> Possibly, but it's also somewhat complicated, and it clogs the list of
> shadow tiddlers if used extensively.
> Also, that workaround is unsuitable for regular users.

I must be missing why regular users would want to do this. As I
recall, the original motivation for the change was to make it easier
for plugin writers to distribute documentation in a separate tiddler
such that the links to the documentation still worked even if the user
deleted the documentation tiddler.

Udo's workaround allows him to ship an optional tiddler with the full
documentation. In situations where it's not available, the user will
instead see a shadow tiddler with a brief note and a link to the
online version of the full documentation.

As I say, I like Udo's workaround because it doesn't introduce any new
complexities into TiddlyWiki, but just elegantly reuses an existing
mechanism.

The proposed mechanism looks to me like something that could be
provided as a plugin, either by extending the existing link formatter
or adding a new formatter. (See Eric's AttachFilePlugin at TiddlyTools
for a related plugin that permits images to be embedded with fallback
to local or online external files).

Cheers

Jeremy

>
> > The trouble with the proposed linking syntax
> > is that it has to be used everytime there's a reference to the tiddler
> > that is potentially missing. That means that if there were a lot of
> > references, updating them would be painful.
>
> That's a good point - though I'm not sure whether it's a deal breaker;
> after all, regular tiddler links are not updated either when the
> respective tiddler is renamed.
> The way I see it, we'd rather have this feature implemented with that
> tiny flaw than not having it at all...
>
> ... except if it would lead to bloat or decreased performance, but the
> respective patch/changeset looks quite harmless.
>
>
> -- F.
>
> >
>

[Martin Budden]

I'm not in favour of this extension to the link syntax. There has been
some effort to bring some commonality to the differing wiki syntax,
see:

http://www.wikicreole.org/

TiddlyWiki markup is very similar to wikicreole and I think that
maintaining that similarity is desirable. This extension would be an
additional deviation from other wikicreole and other wikis.

Martin

[FND]

> TiddlyWiki markup is very similar to wikicreole and I think that
> maintaining that similarity is desirable. This extension would be an
> additional deviation from other wikicreole and other wikis.

I generally agree about WikiCreole compatibility.
However, in this case, the regular link syntax is still present, so this
change would not break any existing links.
Granted, minor problems might arise when transferring contents from TW
to another wiki - but fixing that should be very easy.

Also, rather than being limited by the existing standard, why not push
for a change in that standard?
Martin, you know more about Creole than I do; are they receptive of such
suggestions?

-- F.

[Martin Budden]

One of the things about WikiCreole is that it is modeled on a creole -
that is a stable language that developed out of a combination of two
or more languages. So WikiCreole seeks to use already-existing markup
that is used by other wikis. So WikiCreole is a kind of rationalized
set of the "more popular" markups.

So adding a new format that is not used by any other wiki is counter
to the philosophy of WikiCreole.

Martin

[FND]

> So adding a new format that is not used by any other wiki is counter
> to the philosophy of WikiCreole.

I know - however, I hadn't considered that this kind of functionality is
only really useful for TiddlyWiki (I guess!?).

I'd still like to have this option, but I could also live without it.
After all, it's not like there wasn't an easy workaround (though, rather
than creating a dedicated shadow tiddler, I'd prefer adding a second,
direct link to the external resource).

-- F.

[Dean Tribble]

I'm still just learning about TW, and I wondered whether a variant of
Udo's approach could be made to work and feel like less of a hack (and
still allow Creole compatibility): have the URL specified in the link
definition, and then optionally allow a tiddler to "intercept" the URL
reference.

[[label|URL]]

The part I'm not sure is what would be the best way to implement
this. My current vague theory is with a wikifier that would look to
see if any tiddler was tagged with the URL, and if so, make the
reference link to them instead.

Would a scheme like that work? Could it be done via a plug-in? (If
not, perhaps a future refactoring shoudl allow just overriding the
link-processing behavior :) Would it be "yet another similar magic
mechanism"?

Thanks,
Dean

[Dean Tribble]

In examining the code to figure out a plug-in for my override
alternative, I noticed that the isExternalLink function first checks
for whether there is a tiddler named for the proposed link (presumably
on the theory that tiddler names and URLs do not have overlapping
names). As a result, you can use a URL as a tiddler *name*, and all
links to that "external" URL will instead bring up the named tiddler.
As is, this is probably a bug, BUT a small change or two might turn
this into a very convenient feature. The basic thing missing is the
ability to actually follow the overridden link. I think the ideal
solution is if the title (remember, it's a URL) were to be the real
external link. Perhaps it would be straightforward to make it so that
any mention of that external link from within that tiddler would
resolve to the external link.

I'm not sure whether I prefer the above simple approach to a slightly
more deliberate solution: tiddlers tagged with URLOverride would have
a field with a regular expression of what URL they override (or
perhaps even a rewriting of the URL). To do this, we redefine/
override createExternalLink to check the set of URL overrides before
generating the link.

I think this could be very useful. For example, it allows plug-ins to
refer just to their documentation site, but you could have a local
(possibly abbreviated) copy of the documentation that would be
displayed if present, but that could be deleted without breaking
anything.