Plugin Development - best practices?
Lyall
tedious, as I explore tiddlywiki.
Currently, I have the tiddlywiki open, I test, I do changes directly
to the tiddlywiki html file then do a full Shift-f5 to re-load, then
test and repeat.
The problem is that the tiddler source is 'santitised' for html,
making reading awkward.
I have tried editing my plugin source externally, then editing the
plugin tiddler and pasting in my new source, saving and reloading - I
find this even more tedious than the above method.
What I am looking for, is a better method than this. Surely some of
you guru plugin developers have a better method.
Any suggestions?
...Lyall
Udo Borkowski
<script src="file:///C:/TiddlyWikiProjects/ForEachTiddler/src/Plugin-ForEachTiddler.js" language="javascript" type="text/javascript"></script>
Pressing F5 in the browser will then always reload the latest version of your plugin code (without any extra copy/paste).
Create a tiddler to "test" your plugin and use "permview" make this tiddler the one to be displayed after pressing F5.
I also suggest that you install a debugger on your browser ( e.g. Firebug if working with Firefox)
I am also heavily using Eric's InlineJavaScript plugin ( http://www.TiddlyTools.com/#InlineJavascriptPlugin) to quickly write and test little code snippets.
Udo
----------
Udo Borkowski
http://www.abego-software.de
Saq Imtiaz
I am using external JavaScript script files for development and include them using a <script> tag in a test TiddlyWiki. The easiest way to achieve this is to add a MarkupPostBody tiddler with a content like this:
<script src="file:///C:/TiddlyWikiProjects/ForEachTiddler/src/Plugin-ForEachTiddler.js" language="javascript" type="text/javascript"></script>
Pressing F5 in the browser will then always reload the latest version of your plugin code (without any extra copy/paste).
This is the best way to run the plugin code while developing but it does have a set back. The store and story are not available while developing so not ALL code works this way.
I therefore use a function to loadExternal files right after the regular plugins are loaded.
Step by step:
1) Load the attached file using a script tag in the MarkupPostBody tiddler as Udo has described. I repeat, add the attached file, NOT your plugins file.
<script src="file:///loadExternal.js" language="javascript" type="text/javascript"></script>2) Create a tiddler called ExternalScripts. On a separate line for each file to load, write its relative path.
Eg:
myplugins.js
or
js/myplugin.js
3) Save and reload. Your plugin will load from an external file almost identically to a regular plugin tiddler.
Cheers,
Saq
PS: This will only work while working with files locally.
Create a tiddler to "test" your plugin and use "permview" make this tiddler the one to be displayed after pressing F5.
I also suggest that you install a debugger on your browser ( e.g. Firebug if working with Firefox)
I am also heavily using Eric's InlineJavaScript plugin ( http://www.TiddlyTools.com/#InlineJavascriptPlugin) to quickly write and test little code snippets.
Udo
----------
Udo Borkowski
http://www.abego-software.deOn 7/11/07, Lyall < Lyall....@gmail.com> wrote:
I am trying to write my second plugin and I find the development very
tedious, as I explore tiddlywiki.
Currently, I have the tiddlywiki open, I test, I do changes directly
to the tiddlywiki html file then do a full Shift-f5 to re-load, then
test and repeat.
The problem is that the tiddler source is 'santitised' for html,
making reading awkward.
I have tried editing my plugin source externally, then editing the
plugin tiddler and pasting in my new source, saving and reloading - I
find this even more tedious than the above method.
What I am looking for, is a better method than this. Surely some of
you guru plugin developers have a better method.
Any suggestions?
...Lyall
--
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
Saq Imtiaz
BJ
At work I'm supporting a group of folks all using separate copies of
TW, and to help eliminate variations I've worked hard to split out
both the core code and the plugin modifications, leaving each person
with just a shell on their local PC that calls from a shared common
library. (Everyone uses their TW as a local copy, not over HTTP.)
Doing this split out of the core code was relatively easy, but the
plugins have been another story.
The method Saq describes here just may be what I've been looking for
to make this MUCH easier to do. I'll have to give this a try and see
if it works better... it certainly would be easier to support as I
need to update plugins.
-- BJ
Saq Imtiaz
Interesting...
At work I'm supporting a group of folks all using separate copies of
TW, and to help eliminate variations I've worked hard to split out
both the core code and the plugin modifications, leaving each person
with just a shell on their local PC that calls from a shared common
library. (Everyone uses their TW as a local copy, not over HTTP.)
Doing this split out of the core code was relatively easy, but the
plugins have been another story.
The method Saq describes here just may be what I've been looking for
to make this MUCH easier to do. I'll have to give this a try and see
if it works better... it certainly would be easier to support as I
need to update plugins.
You might also want to look at the loadExternal plugin in ptw. It uses dynamically added script tags and would work online as well. The problem I had with that approach was that the plugin code was not loaded synchronously so dependencies with the core would fail.
With my approach you have the following limitations as opposed to using a systemConfig tiddler:
a) The plugin slices are not parsed.
b) The 'tiddler' variable is not available when the code is eval'd. This is the tiddler variable that gives the tiddler containing the systemConfig code.
Any approach that loads scripts from external files will have this limitation. There are very very few plugins out there that depend on this. The only one I know of is tiddlerList macro.
Except.... give me a few hours or a day, and ill try to whip up v2.0 of this loadExternal script that should get around that limitation too.
Cheers,
Saq
Cheers,
Saq
-- BJ
On Jul 11, 4:38 am, "Saq Imtiaz" <lew...@gmail.com> wrote:
>
> I therefore use a function to loadExternal files right after the regular
> plugins are loaded.
> Step by step:
> 1) Load the attached file using a script tag in the MarkupPostBody tiddler
> as Udo has described. I repeat, add the attached file, NOT your plugins
> file.
>
> <script src="file:///loadExternal.js" language="javascript"
> type="text/javascript"></script>
>
> 2) Create a tiddler called ExternalScripts. On a separate line for each file
> to load, write its relative path.
> Eg:
> myplugins.js
> or
> js/myplugin.js
> 3) Save and reload. Your plugin will load from an external file almost
> identically to a regular plugin tiddler.
>
BJ
On Jul 11, 6:05 am, "Saq Imtiaz" <lew...@gmail.com> wrote:
> With my approach you have the following limitations as opposed to using a
> systemConfig tiddler:
> a) The plugin slices are not parsed.
> b) The 'tiddler' variable is not available when the code is eval'd. This is
> the tiddler variable that gives the tiddler containing the systemConfig
> code.
>
> Any approach that loads scripts from external files will have this
> limitation. There are very very few plugins out there that depend on this.
> The only one I know of is tiddlerList macro.
>
> Except.... give me a few hours or a day, and ill try to whip up v2.0 of this
> loadExternal script that should get around that limitation too.
>
Sounds great to me!! I'm trying out the different plugins that I use,
and so far I haven't seen any that has had trouble loading and
executing.
One thing I did wonder was if there was a reason, or a requirement, to
load the plugins from the external file AFTER the ones stored as real
tiddlers in the store area. I'm wondering if it might make more
sense to load the ones from the external file FIRST... would there be
any reason why you wouldn't want to do that? Just curious...
-- BJ
Saq Imtiaz
On Jul 11, 6:05 am, "Saq Imtiaz" <lew...@gmail.com> wrote:
> With my approach you have the following limitations as opposed to using a
> systemConfig tiddler:
> a) The plugin slices are not parsed.
> b) The 'tiddler' variable is not available when the code is eval'd. This is
> the tiddler variable that gives the tiddler containing the systemConfig
> code.
>
> Any approach that loads scripts from external files will have this
> limitation. There are very very few plugins out there that depend on this.
> The only one I know of is tiddlerList macro.
>
> Except.... give me a few hours or a day, and ill try to whip up v2.0 of this
> loadExternal script that should get around that limitation too.
>
Sounds great to me!! I'm trying out the different plugins that I use,
and so far I haven't seen any that has had trouble loading and
executing.
It wont for the vast majority. Except I know I intend to do some monkey business in the future that will break it. So I need a more solid development platform.
One thing I did wonder was if there was a reason, or a requirement, to
load the plugins from the external file AFTER the ones stored as real
tiddlers in the store area. I'm wondering if it might make more
sense to load the ones from the external file FIRST... would there be
any reason why you wouldn't want to do that? Just curious...
No reason. I cant say that either is better. When I fist wrote this I wanted to do some fancy integration with the Plugin Manager so this order made more sense but I never got around to it.
I have only ever used this to load one plugin at a time when developing. What is the performance like when loading multiple files? Is the loading time much longer?
If you put
config.options.chkDisplayStartupTime = true;
In a systemConfig tiddler you will be shown the time taken to load plugins. It would be interesting to compare the time taken to load the same five plugins from external files vs the normal way.
Any chance I can tempt you to run such a test? ;)
-- BJ
Saq Imtiaz
''Concept:''
* the contents of the external files is loaded and saved as tiddlers.
* these tiddlers are tagged as externalTiddlers
* if the file extensions is ''.js'' then the tag systemConfig is also added, and these tiddlers are loaded by the core as regular plugins.
* you can also load tiddlers that are NOT plugins. View the demo.
* tiddlers with the tag externalTiddlers are not saved when saving the file.
* When editing such an external tiddler, a notice is displayed warning the user that the tiddler cannot be edited.
* A similar warning is displayed when trying to edit and save such a tiddler.
This was originally meant just for development purposes but could be used to load external tiddlers in any situation. It could be extended to use an Http request to allow serverside usage.
Pro's and cons versus the simpler v1 loadExternal script:
* This one allows the plugin code to behave identical to a systemConfig tiddler
* for most plugins, the developer will never know the difference.
Any feedback would be greatly appreciated.
Cheers,
Saq
BJ
> > load the plugins from the external file AFTER the ones stored as real
> > tiddlers in the store area. I'm wondering if it might make more
> > sense to load the ones from the external file FIRST... would there be
> > any reason why you wouldn't want to do that? Just curious...
>
> No reason. I cant say that either is better. When I fist wrote this I
> wanted to do some fancy integration with the Plugin Manager so this order
> made more sense but I never got around to it.
I think loading the external first is better, because that way you can
have an actual config tweak tiddler that will get processed properly.
I tried it both ways, and when the external was loaded last it
"reverted" some settings that had been "tweaked".
>
> I have only ever used this to load one plugin at a time when developing.
> What is the performance like when loading multiple files? Is the loading
> time much longer?
>
> If you put
> config.options.chkDisplayStartupTime = true;
> In a systemConfig tiddler you will be shown the time taken to load plugins.
> It would be interesting to compare the time taken to load the same five
> plugins from external files vs the normal way.
>
> Any chance I can tempt you to run such a test? ;)
>
Certainly!!
I have a core set of 22 plugins, predominately the MPTW set plus a few
others (ForEachTiddler, InlineJavascript, RearrangeTiddler,
DatePlugin, CalendarPlugin, ReminderPlugin, and a few little ones of
my own). Not a small set of stuff, considering how long some of those
are (a total of around 200k in size).
When loading as "internal" tiddlers, the plugins took about 240ms on
average. When loading from the external files, it took about 1 full
second longer... which in the whole scheme of things is really not
that bad.
There was only one plugin I had that wouldn't seem to work loading in
externally, but it was one I really didn't use that much anyway so
it's no loss.
-- BJ
BJ
> Have a look at the attached file, for the updated version of the script.
> This might be overkill for you.... so you might want to stick to the old
> version.
I think I'll have to, because something in version 2 is conflicting (a
hijacked core function issue I'm thinking) that is causing the whole
thing to crash... a pity, because I REALLY like the "external
tiddler" (vs. "built-in shadow tiddler") notation and the block on the
editing, plus being able to use that for more than just plugins.
When I get a chance, I'll send you the full file I have and perhaps
you can see where it's getting hung up.
Thanks, Saq... this looks very promising!
-- BJ
Saq Imtiaz
When I get a chance, I'll send you the full file I have and perhaps
you can see where it's getting hung up.
Please do! If there is nothing sensitive in the file just send it as is. Zip up the directory structure and send it. I would very much like to see what is causing it to crash.
Saq
Saq Imtiaz
No not at all. Also, the actual file loads faster to an extent since it is smaller....
There was only one plugin I had that wouldn't seem to work loading in
externally, but it was one I really didn't use that much anyway so
it's no loss.
Do you remember which one that was? I would very much like to know... perhaps it could be persuaded to comply!
Cheers,
Saq
Saq Imtiaz
TiddlyThemes.com ( http://tiddlythemes.com ) : a gallery of TiddlyWiki themes.
BJ
and don't have a way to send it from here (long story...)
-- BJ
Saq Imtiaz
BJ
I've put it out in a place for you to go and download it:
http://mysite.verizon.net/tampa_geek/TW.zip
It's just a test version I was playing with, so some of it may not
make a lot of sense... but I'm sure you'll have no trouble sifting
through the junk!!
-- BJ
Saq Imtiaz
When in particular was it crashing? Any easy way to reproduce that problem?
Saq Imtiaz
Saq Imtiaz
On Jul 11, 8:33 am, "Saq Imtiaz" <lew...@gmail.com> wrote:
> Have a look at the attached file, for the updated version of the script.
> This might be overkill for you.... so you might want to stick to the old
> version.
I think I'll have to, because something in version 2 is conflicting (a
hijacked core function issue I'm thinking) that is causing the whole
thing to crash... a pity, because I REALLY like the "external
tiddler" (vs. "built-in shadow tiddler") notation and the block on the
editing, plus being able to use that for more than just plugins.
Problem solved. I should have warned you about this. v2 reads the list of files from a tiddler called ExternalTiddlers and not ExternalScripts like v1.
So in your file, change v1 to v2 in MarkupPostBody.
Rename ExternalScripts to ExternalTiddlers.
Voila! It should work!
I would love to hear what you think!
Cheers,
Saq
When I get a chance, I'll send you the full file I have and perhaps
you can see where it's getting hung up.
Thanks, Saq... this looks very promising!
-- BJ
BJ
On Jul 11, 8:51 pm, "Saq Imtiaz" <lew...@gmail.com> wrote:
> Problem solved. I should have warned you about this. v2 reads the list of
> files from a tiddler called ExternalTiddlers and not ExternalScripts like
> v1.
Oh, heck (for lack of a more appropriate but less polite word), I
should have seen that. Why is it always those little things like that
which slip through...
>
> I would love to hear what you think!
>
Overall, I love it! One thing that I'd like to see, if possible, is
to not have all the external tiddlers pop up in the timeline as being
created upon loading. I mean, they ARE being created upon loading,
so it's not really WRONG to have them there, but it's a bit annoying.
Ultimate solution would be to have a separate tab for them to be
listed liked the shadowed tiddlers... have "external" as a parm for
the list macro, just like "shadowed" or "missing", and have them not
appear in the timeline. Or, I suppose, just add "excludeLists" to
make them go away. Either way, seeing them in the timeline or under
the ALL tab kind of defeats the idea of having them "hidden"!
Thinking about it, perhaps you wouldn't always want them to be
hidden... so I'm not sure. If it was just plugins I'd say yes, but
you may have other tiddlers that you'd want brought in from another
file that you wouldn't want hidden. It would be nice to have the
option, I guess.
Another thing to think about... when a tiddler already exists and you
then bring one in externally with the same name, it throws away the
pre-existing one completely. (Certainly made the file smaller,
that's for sure!) I don't know if that is the most user-friendly
behavior, but it may not be avoidable. I think if a tiddler already
exists, it shouldn't be overwritten by an external tiddler... that's
just me.
Even with all of that, this is an extremely useful and quite awesome
piece of work!! I'd definitely recommend it for the base
functionality of TW.
-- BJ
Saq Imtiaz
On Jul 11, 8:51 pm, "Saq Imtiaz" <lew...@gmail.com> wrote:
> Problem solved. I should have warned you about this. v2 reads the list of
> files from a tiddler called ExternalTiddlers and not ExternalScripts like
> v1.
Oh, heck (for lack of a more appropriate but less polite word), I
should have seen that. Why is it always those little things like that
which slip through...
>
> I would love to hear what you think!
>
Overall, I love it! One thing that I'd like to see, if possible, is
to not have all the external tiddlers pop up in the timeline as being
created upon loading. I mean, they ARE being created upon loading,
so it's not really WRONG to have them there, but it's a bit annoying.
Ultimate solution would be to have a separate tab for them to be
listed liked the shadowed tiddlers... have "external" as a parm for
the list macro, just like "shadowed" or "missing", and have them not
appear in the timeline. Or, I suppose, just add "excludeLists" to
make them go away. Either way, seeing them in the timeline or under
the ALL tab kind of defeats the idea of having them "hidden"!
Agreed they should be somewhat hidden. At least the date for them should be such that they are not at the top of the Timeline.
Another thing to think about... when a tiddler already exists and you
then bring one in externally with the same name, it throws away the
pre-existing one completely. (Certainly made the file smaller,
that's for sure!) I don't know if that is the most user-friendly
behavior, but it may not be avoidable. I think if a tiddler already
exists, it shouldn't be overwritten by an external tiddler... that's
just me.
Yup. I thought about that and it definitely should be so. I might work on that. You have to remember this was written just for testing and development of plugins! Not for actual regular TW usage! I only threw in a few extra features quickly after reading how you planned to use it. I will tweak this further.... but the original loadExternal might still be an option for you too.
Even with all of that, this is an extremely useful and quite awesome
piece of work!! I'd definitely recommend it for the base
functionality of TW.
I appreciate the sentiment. However it is quite limited in what it does and where it can work. So its not really suitable for the core. Especially since it only works locally right now. It wont be everyone's cup of tea but perhaps we can get it to the point where it is usable for others in situations like yours.
Cheers,
Saq
Udo Borkowski
Debuggers like FireBug etc. don't work that nicely with dynamically loaded plugins, e.g. it is hard (impossible?) to set breakpoints. So you may want to use different approaches to load a plugin, depending on your development approach/state.
(I haven't tried out loadExternal.js or the ExternalTiddlers stuff, but I assume this is also true for these solutions)
Saq Imtiaz
One thing to consider when using "dynamically loaded plugins" vs. plugins directly included using a <script ...> tag:
Debuggers like FireBug etc. don't work that nicely with dynamically loaded plugins, e.g. it is hard (impossible?) to set breakpoints. So you may want to use different approaches to load a plugin, depending on your development approach/state.
Very good point Udo. I know basic logging and timing works but breakpoints might not. Thank you for pointing this out!
Cheers,
Saq
Udo Borkowski
The store and story are not available while developing so not ALL code works this way.
Udo
----------
Udo Borkowski
Udo Borkowski
This was originally meant just for development purposes but could be used to load external tiddlers in any situation. It could be extended to use an Http request to allow serverside usage.
As you said, this is intended for development/testing. However, if you plan to make this a "general purpose" plugin make sure to have a second look at your SaverBase.prototype.externalize function. E.g. Eric is also redefining this in his TemporaryTiddlersPlugin. As far as I can tell there is no way to have both features running at the same time. Implementing ticket 313 ( http://trac.tiddlywiki.org/ticket/313) should solve this issue (planned for TW 2.3)
Saq Imtiaz
This was originally meant just for development purposes but could be used to load external tiddlers in any situation. It could be extended to use an Http request to allow serverside usage.
Very nice idea!
As you said, this is intended for development/testing. However, if you plan to make this a "general purpose" plugin make sure to have a second look at your SaverBase.prototype.externalize function. E.g. Eric is also redefining this in his TemporaryTiddlersPlugin. As far as I can tell there is no way to have both features running at the same time. Implementing ticket 313 ( http://trac.tiddlywiki.org/ticket/313) should solve this issue (planned for TW 2.3)
I was not aware Eric had worked on this. I dont really want to put too much effort into this, I am waiting for Ticket 313 as well. Ideally I would want TemporaryTiddlers to be field based but I just used tags for now just to get something quick up and running.
The only 'problem' with this loading approach is that it increases the startup time. However, with the release of TW 2.3 I think that I will try to develop this as a general purpose plugin. The current code is very raw and there is much room for improvement, but it works well as a proof of concept.
Cheers,
Saq
Udo
----------
Udo Borkowski
http://www.abego-software.deOn 7/11/07, Saq Imtiaz <lew...@gmail.com> wrote:Have a look at the attached file, for the updated version of the script. This might be overkill for you.... so you might want to stick to the old version.
''Concept:''
* the contents of the external files is loaded and saved as tiddlers.
* these tiddlers are tagged as externalTiddlers
* if the file extensions is ''.js'' then the tag systemConfig is also added, and these tiddlers are loaded by the core as regular plugins.
* you can also load tiddlers that are NOT plugins. View the demo.
* tiddlers with the tag externalTiddlers are not saved when saving the file.
* When editing such an external tiddler, a notice is displayed warning the user that the tiddler cannot be edited.
* A similar warning is displayed when trying to edit and save such a tiddler.
This was originally meant just for development purposes but could be used to load external tiddlers in any situation. It could be extended to use an Http request to allow serverside usage.
Pro's and cons versus the simpler v1 loadExternal script:
* This one allows the plugin code to behave identical to a systemConfig tiddler
* for most plugins, the developer will never know the difference.
Any feedback would be greatly appreciated.
Cheers,
Saq
--
TiddlyThemes.com ( http://tiddlythemes.com ) : a gallery of TiddlyWiki themes.
Saq Imtiaz
The store and story are not available while developing so not ALL code works this way.
To overcome the undefined store/story issue my plugins typically run initialization code (that refers to story/story) after the normal TiddlyWiki startup code. I either use setTimeout for this purpose or hijack the "restart" function.
Yes... I have started doing the same too. Even for cleanliness of code. The macros.init() function is also avaialable now. The problem I am facing now is that some new plugins I am writing are saving settings in the tiddler containing the settings and I want to avoid hard coding the tiddler name. The tiddler variable is not available when loading code from an external script. This was what prompted the idea for creating tiddlers for each loaded script.
Cheers,
Saq
BJ
On Jul 11, 10:28 pm, "Saq Imtiaz" <lew...@gmail.com> wrote:
> On 7/12/07, BJ <bjbacki...@gmail.com> wrote:
> > ... Either way, seeing them in the timeline or under
> > the ALL tab kind of defeats the idea of having them "hidden"!
>
> Agreed they should be somewhat hidden. At least the date for them should
> be such that they are not at the top of the Timeline.
For now, I think the "excludeLists" is probably the right option for
me. I modified the loadExternal script to add that as a tag at the
same time it's adding the "systemConfig" tag. A more robust solution
that I'll play around with is being able to use some parms with each
entry in the "ExternalTiddlers" list, to be able to specify the tags
to be applied (instead of just going by file extensions).
>
> > I think if a tiddler already
> > exists, it shouldn't be overwritten by an external tiddler... that's
> > just me.
>
> Yup. I thought about that and it definitely should be so. I might work on
> that. You have to remember this was written just for testing and development
> of plugins! Not for actual regular TW usage! I only threw in a few extra
> features quickly after reading how you planned to use it. I will tweak this
> further.... but the original loadExternal might still be an option for you
> too.
Oh, I understand that completely, and really appreciate what you did
with it. It's a great start and, as I said, I'd like to take it and
see what I can do with it for what I need. As it is written right now
the script is perfect in the use for which it is intended.
As for the original loadExternal, I certainly think the ability to be
able to see the tiddler as the "external", but not be able to edit it,
makes the newer version a much better option.
>
> Even with all of that, this is an extremely useful and quite awesome
>
> > piece of work!! I'd definitely recommend it for the base
> > functionality of TW.
>
> I appreciate the sentiment. However it is quite limited in what it does and
> where it can work. So its not really suitable for the core. Especially since
> it only works locally right now. It wont be everyone's cup of tea but
> perhaps we can get it to the point where it is usable for others in
> situations like yours.
Duly noted, and knowing that other changes relating to this are in the
works is a promising sign. But you've given me a fantastic boost
forward in being able to support my particular situation with MUCH
less hassle, especially when upgrading versions of plugins. Thank you
so much for what you've done with this and all your other plugins and
extensions.
-- BJ
Lyall
Lyall
I have added this info to
http://www.tiddlywiki.org/wiki/Developing_and_Testing_a_Plugin
I am no wordsmith, so feel free to tidy it up :-)
...Lyall
BJ
> For those that are interested in helping make writing plugins easier,
> I have added this info to
>
> http://www.tiddlywiki.org/wiki/Developing_and_Testing_a_Plugin
A few points:
1) MarkupPostBody is the shadow tiddler that needs to have the
<script ...> call to the loadExternal.js code.
2) InlineJavascriptPlugin isn't needed, since the content of
MarkupPostBody actually gets resolved into the actual HTML after the
core TW code and the little "if(useJavaSaver)" script.
-- BJ
Udo Borkowski
So instead of
<script src="file:///Path/to/the/LoadExternal.js" language="javascript" type="text/javascript"></script>you may write
<script src="file:///Path/to/YourPlugin-src.js" language="javascript" type="text/javascript"></script>
in your MarkupPostBody tiddler
(LoadExternal.js was introduced before we had the Markup tiddlers and no easy way to customize the HTML of the TW.)
Paul Petterson
Paul Petterson
BJ
wrote:
> Actually you don't need the "LoadExternal.js" stuff, but you can directly
> "include" your plugin JS code.
That's a good point, and probably would be an easier solution for most
folks.
For my situation, the separate external "loader" script is ideal,
especially the later version that puts them in as "external
tiddlers" (which don't have to just be plugins) that can be viewed but
not edited. The "external tiddler" concept takes "shadow tiddlers"
one step further in that they can't be edited or overwritten.
However, my situation is probably rather uncommon, so the direct load
of the plugin source is probably more useful for others.
-- BJ (TampaGeek)