Previously, widgets were reading variables from themselves or their
cascaded ancestors. That means that if a widget sets a variable and
then reads the same variable, it will get the same variable back. That
sounds reasonable, until you consider a widget that wants to modify a
variable - eg the tiddler macro. For example:
```
<$tiddler tiddler={{!!report}}>
<$transclude mode="block" />
</$tiddler>
```
Here we first evaluate the `{{!!report}}` reference, which involves
reading the currentTiddler variable, looking up the tiddler, and
retrieving it’s `report` field. The next the tiddler widget is
refreshed, it will use the newly set currentTiddler as the basis for
resolving the `{{!!reference}}` reference.
The fix is to get variables from ancestors, but continue to set them on
ourselves.
1. Moved some methods out of boot.js because they are not needed until
after bootup
2. Added alternate message for editing an overridden shadow tiddler
3. Minor style tweaks
Replace this with a $tw.wiki.isModifiedTiddler(title) as part of the
wiki object. This allows it to be used outside of the current Wiki which
can change.
Should only display the confirmation if the shadow tiddler has not been
overridden in the first place. It checks this by looking for the
existence of a modified field for which the default system based shadow
do not have until a user changes them.
This addresses the second line item on issue #570
We will need new translations for the added string
`ConfirmEditShadowTiddler`
When saving a tiddler we check to see if the tiddler has changed
(isModified) if it hasn't then bounce the event to tw-cancel-tiddler
instead.
Addresses first line item in issue #570
We need to send messages to the parent so that we don’t set up an
infinite loop by sending `tw-navigate` messages. Also we need to pass
along the target of the navigation.
Because:
* It doesn't work well with TW5's refresh mechanism, which relies on
being able to regenerate any portion of the DOM as required; this
frequently causes inline handlers to be re-executed at unexpected times
(see
http://tiddlywiki.com/static/TiddlyWiki%2520for%2520Developers.html)
* It mixes TW5 version-specific JavaScript with user content
* In multiuser environments there is a security risk to importing or
viewing tiddlers you didn't author if they can have JavaScript in them
As described here: https://groups.google.com/d/msg/tiddlywikidev/AWvXz7RMIC4/gFF5crN2UJoJ
Providing a name for the new tiddler message only works if a skeleton tiddler already exists. If not, "New Tiddler" is taken. This change fixes that in that the provided name is taken even if there is no skeleton.
