New: SharedTiddlersPlugin (evolution of IncludePlugin)

[Yakov]

Hello everybody,

today I'd like to announce that the public release of SharedTiddlers plugin is ready [1].

In principle, almost everything, including an introduction, can be found in the repository.

In two words: the plugin allows to

* see tiddlers from another tiddlywikis (as read-only) inside the "main" one

* share theme components (style sheets, templates: PageTemplate, ViewTemplate, EditTemplate, ToolbarCommands) which can be stored in one central TW

* do other things, including sharing evaluated transclusions like "toggle menus" engines from TiddlyTools [2] or "custom" ones (in fact, most of plugins can easily turned into evaluated transclusions, which will be described in the documentation later)

Some major improvements since IncludePlugin [3]:

* now a set of tiddlers (defined by a filter) can be included instead of all tiddlers

* shadows and tiddlers can be "substituted" with the included tiddlers (they are not altered and if including is switched off, they remain the same as they were)

* a notification system for name conflicts is introduced

* elements of themes are now applied on load

* wikifyIncluded macro is introduced (see docs)

* simple "importing" engine is added

* slices are recalculated according to the presence of new tiddlers

* documentation on how to make plugins "include-aware" is added (and pieces of code that make abego plugins "include-aware" are removed from the main code)

Feedback is welcome. Though, I'm rather slow in my development, so take this into account. Also, if you have some "basic" questions, please take a look at the docs first and let me know if I missed something there.

Best regards,

Yakov.

PS there are some plans for further development including

* evaluation system for plugins (to remove the need of making evaluated transclusions)

* aggregation tools for analysing data (search and other) among several TWs simultaneously (accounting name conflicts)

but I can't predict how soon I implement this.

[1] http://yakovl.bplaced.net/TW/STP/STP.html

[2] http://www.tiddlytools.com/#ToggleLeftSidebar%20ToggleRightSidebar

[3] http://tiddlywiki.abego-software.de/#IncludePlugin

[Yakov]

Almost forgot. Unfortunately, recent versions of FireFox cut the including abilities of TiddlyWiki as well, while TiddlyFox solves only saving issues, so with FF 17+ you probably wouldn't be able to use this plugin unless Jeremy succeeds with such issues through TiddlyFox, or another way to load files is found (by me or by others).

[magev958]

Sorry, I can't get to your site, just some random commercial :(

[Yakov]

Hi,

Oops, sorry, bplaced blocked my account because I haven't loggined (not via FTP) for 3 month. As a "quick fix", here's an attachement which contains the repository, including TWs from which some tiddlers are included for an example.

By the way, current version should work in FireFox when used in TW 2.7.0 (I haven't tested directly, though) and the next (1.5.0) is working with tw 2.6.0 + FF 17 (will be released later, I'm developing advanced import/autoimport features).

вторник, 8 января 2013 г., 14:28:09 UTC+4 пользователь magev958 написал:

[David Szego]

Yakov, this is a really neat plugin - yasher kayach to you! One suggestion - you should include a link to your repository, so this plugin would be self-updating by always including the latest version!!

Cheers,
David.

[Yakov]

Hi David,

thanks. What do you mean by "include a link to the repository"? There's the Source slice in the plugin tiddler, which contains the link to the source.. Do you mean just direct link to the plugin tiddler in addition to the source tiddler, or adding an additional engine for self-updating?

Now the repository [1] is up, so TiddlyWiki's sync mechanism can probably be used for updating (it is removed in TW 2.7.0 or 2.6.6 though). On the other hand, auto-importing engine will be introduced in STP 1.5.0 and then, when I enable including from web (now I have some guidelines how to do this), it also can be used for auto-update (but this will be after v1.5.0). So stay tuned (you can subscribe for comments in this thread by clicking the envelope symbol, on the top of the scrollable part of this page [if you use the new google.groups interface]).

Best regards,

Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html

среда, 9 января 2013 г., 6:06:42 UTC+4 пользователь David Szego написал:

[Yakov]

Hm, strange, seems that my latest message got deleted.

Anyway, the new version of the plugin/docs is ready [1]. The main changes are:

* now STP works with FireFox 15+ even in TWs prior to 2.7.0

* autoimport via the <<include>> macro is added (prime purpose is to enable plugin centralization)

* import now causes the "leave page without saving?" prompt to appear (in browsers which support it, Opera is not a such one)

* "protection" from including/importing empty tiddlers (created by the "tiddler" filter) is introduced

The next version probably won't appear soon; I plan to implement evaluation of included plugins "on the fly" and may be including from web in it.

Best regards,

Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html ; if you have problems with opening the repository, please report here and download the attachment instead

[Yakov]

Hi Doru,

it should work: I use it heavily in my Android device, now I took another one and.. it works with AndTidWiki on both Android 2.3.6 and 4.0.3 and also works with FF 14 and latest FF beta with TiddlyFox on Android 2.3.6 but on Android 4.0.3 with both FF and FF beta don't work for me (though, these tests are for STP 1.6.0 which is not released yet, but 1.5.0 also worked for me in Android 2.3.6 with all the apps).

Could you specify what Android version, TW version and STP version do you use along with the macro definitions you use?

Best regards,

Yakov.

среда, 20 февраля 2013 г., 16:19:43 UTC+4 пользователь doru написал:

Hello Yakov.

Thanks for sharing your work.

I tried without much success to use SharedTiddlersPlugin on Android (through AndTidWiki and Firefox for Android).
Do you know if SharedTiddlersPlugin is supposed to work on Android devices?

Thanks.

[Yakov]

All right, guys, today I'm rather excited to announce that STP 1.6.0 is released. This major version allows to launch external plugins directly, without importing them. There are few details to improve, but in general that's the last (major) version of the 1.x series focused on sharing settings and engines between TWs.

The new feature is implemented via the <<include>> macro and the new "eval" parameter: for instance,

<<include "sharedPlugins.html" filters:"[[CollapseTiddlersPlugin]] [[RearrangeTiddlersPlugin]]" eval>>

would include the two plugins (I'm referring to the plugins from TiddlyTools [1]).

Other changes include

* added new filters "all" and "includedFrom"

** now STP requires core version 2.6.2 or the UpToDateFiltersPlugin which can be found in the repository (it enables extensible filters in elder versions of TW)

* the "hide" parameter now can be used simply as <<include ... hide> instead of <<include ... hide:true>>

* improved API and documentation of API

* some fixes and code improvments (size reducing ones)

There will probably be a couple of 1.6.x versions improving some details and then, I'll focus on the content sharing, editing and "viewing on different angles" experience. Also, when I finish my centralized system of settings, I'll probably publish some guidelines about how to easily improve you workflow (and may be mobile one too).

As for now, the new version is, as usually, in the repository [2] and attached here.

Best regards,

Yakov.

[1] http://tiddlytools.com/#RearrangeTiddlersPlugin%20CollapseTiddlersPlugin

[2] http://yakovl.bplaced.net/TW/STP/STP.html

[Tobias Beer]

High time to take a closer look at STP. Thanks, Yakov!

[Tobias Beer]

As a sidenote, I think siders work better for a PluginInfo tiddler... especially when titles is rather long. Come to think of it, I guess sliders were more handy, if one could (CTRL+)CLICK on the contents to close the slider again and scroll back to the button.

Also, other than using tables to list parameters, I've come to like definition lists...

; option

:» description

...to document alternative options. Looks better than some form of....

option: description

...with a list of options.

The amount of information for STP is quite overwhelming. Some things are not quite clear, esp. "include aware". It's also a bit confusing that you seem to speak of "hijacking" core functions whereas your API actually provides alternative functions ith no actual hijacking taking place... am I wrong?

Cheers, Tobias.

[Yakov]

Hi Tobias,

воскресенье, 24 февраля 2013 г., 16:59:24 UTC+4 пользователь Tobias Beer написал:

As a sidenote, I think siders work better for a PluginInfo tiddler... especially when titles is rather long. Come to think of it, I guess sliders were more handy, if one could (CTRL+)CLICK on the contents to close the slider again and scroll back to the button.

Thanks, that's what I needed, feedback about documentation. As for sliders, I dont think that's a good idea, unless I add an evaluated transclusion which adds an event handler which would close sliders on ctrl+click or so -- I hate the need to scroll back and then down again. That's why I chose tabs (but scrolling up is needed anyway).

Tabs create that grey background by default -- may be that's what you don't like? I'd agree and I created a small transclusion which added to the end of the Info tiddler (not published that yet) which changes background color:

<<tiddler {{setStylesheet('div[tiddler="SharedTiddlersPluginInfo"] .tabContents { background-color:'+store.getTiddlerText('ColorPalette::Background')+'; }', 'STPInfoCSS');'';}}>>

Probably will add this to the repository with the new version.

 

Also, other than using tables to list parameters, I've come to like definition lists...

; option

:» description

...to document alternative options. Looks better than some form of....

option: description

...with a list of options.

Well, the table is a short summary (with many colomns, so I don't really see how switching to lists would make this better), and inline descriptions are below..

 

The amount of information for STP is quite overwhelming. Some things are not quite clear, esp. "include aware". It's also a bit confusing that you seem to speak of "hijacking" core functions whereas your API actually provides alternative functions ith no actual hijacking taking place... am I wrong?

Yeap, that's the main issue about the docs, their amount. What do you think can be changed here? I added "Basics" section so that one can start from easy things, but even with all those tabs, the "How to use the SharedTiddlersPlugin" is very big. May be I need another logic of description, rather that "reference book"'s one.

"Include aware" term is connected with the way hijacking is done. Actually, the explanation is in the "Making other plugins "include-aware"" section:

* store.fetchTiddler is actually hijacked

* store.forEachTiddler is not hijacked, Udo's documentation sais that it's done to avoid included tiddlers get saved in the main TW document;

  instead, different core functions are hijacked with the getFunctionUsingForReallyEachTiddler method (of config.extensions.SharedTiddlersPlugin) so that when they are launched,  store.forEachTiddler get hijacked and after they are called, it is restored again. Not a very elegant technique, but it works (I'm not sure if this can be dangerous when things are done "in parallel" like when setTimeout is used)

So, if some functions in another plugin do smth using store.forEachTiddler, depending on what this is, those functions can be modified getFunctionUsingForReallyEachTiddler as well -- or be not modified which can be desirable if they some saving stuff.

May be there's another way to handle this.. some sort of "forbidding saving for included tiddlers" which which store.forEachTiddler can be actually hijacked. I should think of this, that's not a simple issue.

As for the orig_fetchTiddler, well, it doesn't prevent fetchTiddler being hijacked. Just take a look at the source, and you'll see:

  var orig_fetchTiddler = store.fetchTiddler;
  window.sharedTiddlersAPI.orig_fetchTiddler = orig_fetchTiddler;
  // reserve access to the original method to be able to fetch tiddlers from main store,
  // including substituted ones

  store.fetchTiddler = function(title) {
  ...

Here's a pecularity: I was thinking that if I create a variable (orig_fetchTiddler) then there are two copies of the function and changing window.sharedTiddlersAPI.orig_fetchTiddler won't cause any changes in store.fetchTiddler, but I probably was wrong.. That's not very important, though..

Will be glad to hear further notes.

Best regards,

Yakov.

Cheers, Tobias.

[Smandoli]

I am thrilled with SharedTiddlersPlugin. 

I have a TW for notes.  It references a companion TW which handles voluminous static information (specifically, an English Bible translation). 

• Both documents use TW version 2.7.0 beta 2. 
  
• They are held on a USB drive which is accessed from two computers, a Win7 PC and a laptop running Mint.  Rendering via Firefox 18 and 17, respectively.  TiddlyFox is in there two.
  

Speed is impressive, performance is reliable, and excitement is high.  THANKS!

[Yakov]

Hi Smandoli,

glad to hear that the plugin is already useful (despite the fact that it requires much more work for my applications). Yeap, you usecase is what STP is exactly suitable for.

Please let me know about the performance if you try mulitple inclusions. For me it creates a bit of delay on startup because of multiple refreshing (I test mostly in Opera and AndTidWiki); though, I'm going to add the noRefresh parameter to handle this.

Positive feedback is nice to hear, thanks :)

Best regards,

Yakov.

пятница, 1 марта 2013 г., 5:32:33 UTC+4 пользователь Smandoli написал:

[Mat]

On Sunday, December 16, 2012 1:00:45 AM UTC+1, Yakov wrote:

Almost forgot. Unfortunately, recent versions of FireFox cut the including abilities of TiddlyWiki as well, while TiddlyFox solves only saving issues, so with FF 17+ you probably wouldn't be able to use this plugin unless Jeremy succeeds with such issues through TiddlyFox, or another way to load files is found (by me or by others).

Does this still hold - ie. is it not possible to use on FF17+ and also not with TiddlyFox? Darn annoying how the browser creators change these things.

Has anyone tested to share between different "forms" (for lack of better term) of TW's, ie between eg "local copy and tiddlyspot copy"? "local and tiddlyspace"? etc.

Thank you!

<:-)

[Mat]

...and I forgot to express my gratitude for creating this! I've longed for this a very long time!! Thank you Yakov!

[Yakov]

Hi Mat,

so what's your result? Does STP work for you?

In fact, the problems in FF have nothing to do with TiddlyFox, it had problems with FF priveledge managment system. Recent versions of STP should work fine (and elder ones work fine in TW 2.7.0+). However there are some issues unsolved for FF:

* for me, STP doesn't work in FF for Android in Android 4.0.3 (while it works in Android 2.6.3)

* FF refuses to include TWs outside the folder where including TW is (no relative paths with "../ .... ")

* once or twice I had problems in FF in Windows, but I can't reproduce them now, even with the previous versions of STP

Because of the first problem, I'll dig this anyway, but as I use FF in Windows quite rarely, I'm not sure how soon (there are many more things to with STP).

Best regards,

Yakov.

понедельник, 11 марта 2013 г., 17:41:29 UTC+4 пользователь Mat написал:

[Scott Simmons]

This is terrific!  I started using IncludePlugin seriously only last year, and STP extends the possibilities into exciting new territory.

I'm just now working my way through the documentation (which is greatly appreciated!) and may have a couple of questions.

For example, this line confused me a little:

* it is implied that shadows are not added after {{{<<include>>}}} macros are handled (otherwise some notifications will appear as in the {{{ambiguity}}} case while after a shadow is added it can become the {{{sh ambiguity}}})

Maybe someone can restate/explain it for me?

[Scott Simmons]

Another question about the documentation.  (Sorry for posting separately, but I don't want to forget them as I'm working my way through between sandwich bites.)

[Example] will load two plugins and evaluate them as ~JavaScript.  (they can have no {{{systemConfig}}} tag).

From what I can tell, that means the two included plugins don't NEED a systemConfig tag to be loaded and run in the main TW as long as they're included using the macro call Yakov documents -- but it reads as if they CANNOT have the systemConfig tag without causing problems.  If I'm interpreting it correctly, including a plugin from another TiddlyWiki where the plugin is tagged "systemConfig" shouldn't cause any problems.

[Yakov]

Hi Scott,

воскресенье, 7 апреля 2013 г., 7:29:18 UTC+4 пользователь Scott Simmons написал:

well, this is tiny details, actually. Th story is the following: when a tiddler is added, the plugin checks if it adds any name conflicts. If the tiddler has no priorities, STP simply looks if there's any other tiddler with the same name (and if there's one with "substitute" priority, no conflict is believed to present). However, it's a bit more complicated when the included tiddler has the "substitute shadows" priority. If there is a shadow with that name [in the moment or inclusion], STP looks only for other tiddlers with such priorities (they are conflicting as each of them is supposed to substitute the shadow); if there's no such shadow, STP looks for all other tiddlers with that name. But if a shadow is added *after* the inclusion, this scheme can hold extra conflicts (this now can only cause incorrect notifications, nothing more).

In fact, I'm going to improve documentation by separating the main "How to use" tab into something like "possibilities overview" and "technical details" so that people wouldn't need to make their way through all those details. By may be I'd better release STP 1.6.1 first and postpone this for the STP 2.0.0 release I'm working on these days.

As for you second question, you're right, I meant that systemConfig is not necessary (wrongly translated into English). I'll correct that in the next release.

Best regards,

Yakov.

[Yakov]

Ok, STP 1.6.1 is released [1]. It contains one bug fixe (ImportIncluded engine didn't work in STP 1.6.0) and documentation improvements, and also this features:

* noRefresh option of the include macro -- allows to avoid multiple refreshing because of multiple incuding which can sometimes slow down startup

* "internal" filter which filters out external (included) tiddlers

Best regards,

Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html

воскресенье, 16 декабря 2012 г., 2:42:51 UTC+4 пользователь Yakov написал:

[Yakov]

Hello all,

today I'm proud to announce the brand new STP 2.0.0. In fact the changes in functionality don't look that impressive, but introduction of TwWeb required much coding and testing and will be fruitful in further versions.

So, what was changed?

TwWeb -- is a system tracking TiddlyWikis (nodes) inside a virtual "web". As for now, there's new

<<describeNode nodeName "node path/file name.html">>

macro. It adds a description of a node to the TwWeb; node names can be than used in the <<include>> macro like this:

<<include "node: nodeName" ...>>

What advantage does this add? Currently, the main one is that <<describeNode>> accounts the source of the tiddler it was handled in which allows to use relative paths only and painlessly move/rename nodes.

For instance, if you put into the IncludeList

<<describeNode "commons" "../commons/commons.html">>

<<include "node: commons" filters:"[[CommonsHub]]" wikify>>

and then put

<<describeNode "someExtensionRepository" "./extensions/someExtension.html">>

<<include "node: someExtensionRepository" filters:"[[SomeExtension]]" import:4>>

to the CommonsHub, the latter include macro will be corretly treated in the initial TiddlyWiki (with IncludeList), despite that the "./extensions/someExtension.html" url is incorrect for it (correct one is "./commons/extensions/someExtension.html").

While this all sounds complicated, this already work for me quite well and in future versions I'm going to implement at least links like [[link text|tiddler name]]@nodeName which will require only <<describeNode>> macro. For now, it is recommended to try <<describeNode>> and, ideally make all your <<include>> macros use node names instead of url directly.

***

Other changes are:

* <<include>> macro got a new parameter: wikify, which causes wikification of included tiddlers, obviously; <<wikifyIncluded>> macro is now deprecated and throws alerts about it (it still works, but in the next version I'm going to cut its functionality and leave the notification only).

* some minor changes/fixes

** now STP works for me in FireFox and Android 4.0.3, looks like all the "a.fetchTiddler is not fuction" issues had gone

* major update of the documentation, new "Functionality and examples" section will ease reading about functionality, without digging those filters, priorities etc

** though, the new section is not very small and all the suggestions about documentation are welcome

Best regards,

Yakov.

------

PS May be you don't know that you can subscribe for email notifications about new comments in this thread; if you are interested to stay tuned, check the popup button under the thread title (next to the "g+1" button).

воскресенье, 16 декабря 2012 г., 2:42:51 UTC+4 пользователь Yakov написал:

Hello everybody,

[Yakov]

Hi guys,

learning wikifier took more time than I expected, but now.. time for a bit of magic.

In STP 2.1.0 extended prettyLinks are introduced:

   [[label|tiddler name]]@nodeName

basically includes [[tiddler name]] from the node nodeName and then behaves as an ordinary prettyLink [[label|tiddler name]]. There's also extended syntax

   [[label|tiddler name]]@nodeName@options line@

where options line is treated as the options line of the include macro: one can put import:4 or substitute etc in there.

This can be especially useful in mobile devices, where inline include macros would be too bulky. Perhaps, in future versions it will work even for conflicting tiddlers. See other details in docs and keep in mind that tiddlers binded in such a way are not seen by the search engine until they get included.

Other changes:

* the all filter now can be used in the [all[with included]] syntax which has an obvious meaning

* the wikifyIncluded macro has lost its functionality, now it only reminds to use <<include ... wikify>> when is handled

* in the repository, there's an extended description of the PureStore format (in a separate tiddler [1], there's a link in the SharedTiddlersPluginInfo as well)

* I've tested the behaviour of the include macro when the url param contains ".." parts. It turns that Opera, Safari and IE work with such addresses and Chrome and FireFox don't work (don't include); this is added to the docs, additional reports about this are welcome

* I've found the cause of the "a.fetchStore is not a function" bug and fixed that (at least for those cases that I've revealed)

Best regards,

Yakov.

PS the [[label|tiddler name]]@nodeName syntax is compatible with TiddlySpace, right?

[1] http://yakovl.bplaced.net/TW/STP/STP.html#PureStore

воскресенье, 16 декабря 2012 г., 2:42:51 UTC+4 пользователь Yakov написал:

Hello everybody,

[julien23]

Hi Yakov

* FF refuses to include TWs outside the folder where including TW is (no relative paths with "../ .... ")

I am trying to replace LoadTiddlerPlugin that have the same issue.

Is it something you managed to go through with STP ?

I have read Eric managed this with TiddlyWiki version 2.7.2 BETA 1

you can now  successfully import tiddler from files that are outside of the current folder. 

https://groups.google.com/d/topic/tiddlywiki/W4_yyzmgeEA/discussion

Looking forward to read from you

Julien
 

[julien23]

Hi Yakov

your example

<<describeNode "commons" "../commons/commons.html">>

features a relative link to parent directory ../
did you finaly had it work ?
with FF or another browser ?

Regards

Julien

[Yakov]

Hi Julien,

I've made a number of tests which is reported in the docs [1], "Detailed reference" section, after the examples of different urls. In short, I succeeded with including from "../some path" in Opera, Safari and IE but FF and Chrome refused to work that way. I think I tested that in TW 2.6.0. As for the TW 2.7.2, could you please test it with FF + STP 2.1.0 yourself? I'll have a look and report when I release STP 2.2.0, but there's an amount of work to do first..

Best regards,
Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html#SharedTiddlersPluginInfo

суббота, 25 мая 2013 г., 20:04:52 UTC+4 пользователь julien23 написал:

[julien23]

Hi Yakov

On my side ../ fails with STP 2.1.0 on Opera 12.15, FF21 and chrome 27.0.1453.94

Looking forward for STP 2.2

Thanks a lot

Regards

Julien

[Yakov]

Wait, doesn't work with Opera? That's weird: for me it surely works with Win7 x64 + Opera 12.15 + TW 2.6.5 + STP 2.0.0 as all my local plugin microrepositories update STP via autoimport from some "../STP repository path" (and they did that successfully). And STP 2.1.0 haven't introduced any changes about interaction with file system. Let me know your chain of component versions (OS [+ Opera] + TW [+ STP]). Also, you can try this: grab the full (not minified) version of the plugin from [1] and comment out the lines

	if(version.major < 2 || version.major == 2 && version.minor < 7) {

and

	} else
		return httpReq("GET",url,callback,params);

(those are lines #105, #133, #134). I'd hardly believe that, but may be some internals of httpReq were changed in the recent versions of TW so that it no longer works with such paths.

Best regards,
Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html#SharedTiddlersPluginCode

воскресенье, 26 мая 2013 г., 2:47:47 UTC+4 пользователь julien23 написал:

[Arc Acorn]

My test:

<<include "../test/tt1.html">>

works fine:

FireFox 24x64-Nightly, TW Core: 2.7.0 & 2.7.1, STP 2.1.0

DOSE NOT work under:

FFx32 - 20, 21, 22 or 23

[julien23]

Yakov,

your chain of component versions

Win7 pro X64 + Opera 12.15 X32 (fresh install) + TW 2.7.2 (fresh install) + STP 2.1.0
it also fails with
Nightly 24.0a1 X64 (fresh install)

folder structure :
file:///S:/capsule_prospect/empty.html
file:///S:/airbank_tw/empty.html

IncludeList
<<include "../airbank_tw/empty.html" >>

Error when including '../airbank_tw/empty.html':

comment out the lines

same error :(

[Arc Acorn]

^-^;

My bad I forgot in my nightly build I have:

"security.fileuri.strict_origin_policy" set to false 

Which is why it works...

So out of the box no Firefox build works though if you are okay with the added security risk you can set the above setting to false in any build of Firefox  (that I know of) to allow it to work.

[Yakov]

Ah, ok, now Arc's test makes sence. Arc, where this option is set? I'll probably add this to the "Detailed reference" part of the docs.

This reminded me that in Opera I actually had set another option as well -- back when with IncludePlugin including didn't work at all without it (it is mentioned in the "Installation, configuring and troubleshooting" section). The same issue may have applied to Chrome. Anyway, Julien, give a try of both Opera and Chrome with those parameters [1] if haven't yet.

[1] http://tiddlywiki.com/#[[TiddlyWiki%20Browser%20Compatibility]]

воскресенье, 26 мая 2013 г., 22:27:48 UTC+4 пользователь Arc Acorn написал:

[Arc Acorn]

In Firefox's URL bar type: about:config

Search for: security.fileuri.strict_origin_policy

Set to / Toggle to: false

[Yakov]

Magnificent. Thanks Arc, that worked for me (FF 20.0).

воскресенье, 26 мая 2013 г., 23:47:52 UTC+4 пользователь Arc Acorn написал:

[Yakov]

Moreover, I've tested Arc's recipe in Android (4.0.3) with FireFox 14.0 and it worked even there.

понедельник, 27 мая 2013 г., 22:21:32 UTC+4 пользователь Yakov написал:

[Yakov]

Right, ladies and gentlemen,

one (or may be few) more steps to the smooth twWeb workflow. STP 2.2.0 got the following changes:

* <<describeNode someNodeName self>> syntax marks the name someNodeName as the name of the current TiddlyWiki and including from that node is forbidden (if tried, nothing happens)
** this is done to avoid some conflicts, including unnecessary conflict messages and disabling editing of a tiddler included from TW "A" to TW "A" with substituting (this can happen because of transitive including)
* included tiddlers now have an additional toolbar panel in the edit mode. As for now, it contains only a link to the origin tiddler in the source TW -- which improves workflow of editing. It's planned to improve the panel further -- add an "import" button and probably turn the panel into an actual toolbar macro. This feature doesn't require any changes in the EditTemplate as it's a hijack of the edit macro; the panel has manageIncludedPanel class so that stylings can be adjusted
* some internal code changes are done as well to make further changes closer

In addition, the way to configure FireFox so that it includes from "../some path" is added to the "Installation, configuring and troubleshooting" section of docs, thanks to Arc.

Best regards,
Yakov.

PS Julien, so have you succeeded with "../path" urls? I'm interested in further investigation regarding Opera (and probably Chrome too).

[Steve Rutter]

Yakov,

I am using your plugin to perform some collaboration magic at my work. I may have missed it, but I need to make sure all the following are possible. Given 3 files, a "source" TW containing a large amount of content, and 2 "user" files, which are blank using a customized TW as a template. The "user" files include the "source" and the other "user" files, and the "source" includes the "user" files.

Source has a tiddler named "test". User A can see "test", and decides to update the tiddler. In my TW this is possible, but it only modifies it for user A. This is fine. User B looks at "test" and now there are 2 versions of it. I need to make sure user B sees the latest of the 2 versions. In addition, if user B updates the "newest" of the tiddlers, even though user B's physical version is the old, it overwrites the old one (I think this will happen in any case in my TWs). Then, the "source" and User A should see User B's copy as the "newest". Is this functionality included in the plugin, or does it have to be written in?

I don't have more than 20 people working off of these at a time, and I think they can communicate enough to ensure they don't edit at the same time, plus I'll be having some policy involved that will help with that.

Thanks.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.

Visit this group at http://groups.google.com/group/tiddlywiki?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Yakov]

Hi Steve,

first, let me mention that I'm glad to hear about different use-cases, especially those including collaboration process (so I'd appreciate further report about how it went if you don't mind).

Second, the thing you're talking about sounds quite doable, but with certain limitations. I'll provide straightforward details how to implement first and then discuss some details.

Now, if I understood you correctly, there's no difference between the "source" and "user" TWs in terms of how they interact, each one should see versions from each. If so, I suggest the following scheme:

* each TW gets STP
* IncludeLists in TWs other than "source" contain
<<describeNode source "url_of_the_source">>
<<describeNode thisNodeName self>> (change thisNodeName, of'course)
<<include "node: source" filters:"[[TwWebHub]]" wikify>>
* IncludeList in the "source" contains
<<describeNode source self>>
<<tiddler [[TwWebHub]]>>
* TwWebHub in the "source" contains
<<describeNode nodeA "url_of_the_node_A">>
<<describeNode nodeB "url_of_the_node_B">>
...
<<include "node: source" filters:filter_describing_shared_tiddlers import:4>>
<<include "node: nodeA" filters:filter_describing_shared_tiddlers import:4>>
<<include "node: nodeB" filters:filter_describing_shared_tiddlers import:4>>
...
* finally, you have to design the filter_describing_shared_tiddlers filter: it may be "[tag[some tag for shared tiddlers]]" or smth more complicated

This is a "governing" approach, where the "source" TW contains all the <<include>> macros as well as almost all <<describeNode>> macros are written in only one place. Pluses and minuses are evident: advantages are that adding a new node, renaming etc should be done only in one place, and if smth goes wrong, everybody should probably notice. This is good when the operator of the "source" is always present. Disadvantages are: a mistake of the "source" operator will cause problems for everybody and if the operator doesn't act fast, (s)he hinders others. One more problem can be increase of the load time.

Another possible approach is when everybody fills their IncludeList with all those include (and may be describeNode) macros. This is quite a messy approach, but looks like "more freedom for each one". In fact, I wouldn't recommend to use this approach -- instead, you can start from the "governed" approach and then if someone need to customize, (s)he just goes to their IncludeList and change stuff there. In principle, there can be more complicated ways, which imply not just one Hub, but rather a set of them and tricky system of transclusions etc.

Now, how does this work and what limitations I can see. First, a smaller one, is a workflow issue that I can handle in the next version as it was planned anyway: import has only two modes -- "1" (import anyway, doesn't fit) and "4" (import only newer versions and after confirm of the user). The issue is workflow can get flooded with those "import?" confirmations. The solution is to add another import mode, obviously (or you can create a quick hack yourself -- but keep in mind that my plan is to name the mode "import only newer version" as "2"). Second, more important limitation, is that you can't receive updates other than by reloading your TW. Though, I'm going to implement "reload on demand" at some point, but this is still "manual controlled" reloading. In principle, after reloading engine is established, it is even possible to have it reload each period of time. But it's not possible (without a server-side part) to receive updates "as they are pushed".

And yet, even those "possible" features are to be implemented. I'm not a very quick developer (not a professional coder actually) and I have to get my master's degree in June, so please consider those features as "appearing in the far future". Though, implementing the "2" import mode isn't difficult at all.

Best regards,
Yakov.

четверг, 30 мая 2013 г., 8:13:24 UTC+4 пользователь bluespire написал:

[Steve Rutter]

I'm looking forward to that "import: 2" option. Until then, I'll probably just remove the Alert (haven't looked at code yet, assuming it's an Alert) for the time being.

In my scenario, every TW must see every user created tiddler, so no tag filtered inclusions. However, it would be great to have tag filtered EXCLUSIONS. For instance, a user tags a tiddler with "private" because it either contains sensitive data, or maybe is a draft not meant to be published yet. Since you pointed out to me that all the inclusions can be handled centrally, I wouldn't have to worry about a user modifying their inclusions to see someones sensitive data or drafts. In my case, I don't think managing centrally will reduce flexibility, since all user TWs are intended to be the same, with the exception of the content.

If I understand the point of "describeNode", it is used to trick TW into thinking the content of the include is actually a set of tiddlers, which are therefore made available to be directly included.

Will the "import: 4" option work as I previously described? I think the only reason I can do it without that option, is that CKeditor is being invoked even when "view" is pressed, and its save is overriding the imported tiddler and making it a real (updated) tiddler. If the option 4 works the same way, but will actually show the "edit" button by default, that would be great. I assume my users are not savvy and don't want to confuse them when it shows view vice edit, but it actually edits in any case.

I'll give you a little more background on what I'm doing here. I work is a very locked down workplace. Getting anything approved to be installed requires teeth pulling, and even then, few solutions provide the flexibility that TW does. I need collaboration, as I'm using TW as a knowledgebase. All the TWs reside in a single folder on a network drive. There will be one TW named after each user, plus the source TW maintained by a designated manager.

As great as TW is, I will, eventually, start running into scaling issues regarding performance. This is why I need as much flexibility in pulling static content and generating dynamic content (such as foreachtiddler).

[Yakov]

Ok, here I'll provide some quick solutions you can use, but release them in the "official" repositories later.

четверг, 30 мая 2013 г., 15:53:14 UTC+4 пользователь bluespire написал:

I'm looking forward to that "import: 2" option. Until then, I'll probably just remove the Alert (haven't looked at code yet, assuming it's an Alert) for the time being.

Here's the solution: grab SharedTiddlersPluginCode [1], insert between

            case 1: { // import anyway
                doImport(t);
                break
            }
            case 4: { // import only newer and on confirm
                tInMain = window.sharedTiddlersAPI.orig_fetchTiddler(t.title);
                if(!tInMain || tInMain.modified < t.modified)
                    if(confirm("Up-to-date "+t.title+" from "+url+" is availabe, import?"))
                        doImport(t);
                break
            }

blocks another one:

            case 2: { // import only newer versions/unexisting tiddlers
                tInMain = window.sharedTiddlersAPI.orig_fetchTiddler(t.title);
                if(!tInMain || tInMain.modified < t.modified)
                    doImport(t);
                break
            }
 
(check the spaces, usually google.groups add non-breaking spaces if you just copy-pase smth). Than you can use that tiddler instead of STP (just rename it). You can also minify the code with google compiler [2] or wait for the full release.

In my scenario, every TW must see every user created tiddler, so no tag filtered inclusions. However, it would be great to have tag filtered EXCLUSIONS. For instance, a user tags a tiddler with "private" because it either contains sensitive data, or maybe is a draft not meant to be published yet. Since you pointed out to me that all the inclusions can be handled centrally, I wouldn't have to worry about a user modifying their inclusions to see someones sensitive data or drafts. In my case, I don't think managing centrally will reduce flexibility, since all user TWs are intended to be the same, with the exception of the content.

Well, I'm on my way of releasing the ExtraFIlters repository, but I'll put the filter you need right here. NotFilterPlugin:

/***
|''Version''|1.0.1|
|''Requires''|UpToDateFiltersPlugin|
|''Note''|requires UpToDateFiltersPlugin only if TW core version is 2.6.2 or above|
***/
//{{{
config.filters.not = function(results,match) {

    // parse the argument as "filterName[filterParam"
    var dividingRE = /([^\[\]]*)\[([^\]]*)/,
        filterParts = dividingRE.exec(match[3]);
    if(filterParts) {
        var filterName  = filterParts[1],
            filterParam = filterParts[2];
    } else
        throw("\"not\" filter: wrong syntax");

    // create the set of filtered tiddlers
    var filter = "[" + filterName + "[" + filterParam + "]]",
        tids = this.filterTiddlers(filter);

    // collect tiddlers present among "results", but not among filtered tiddlers
    for(var i = 0; i < results.length; i++)
        for(var j = 0; j < tids.length; j++)
            if(results[i] == tids[j]) {
                results.splice(i,1);
                i--;
                tids.splice(j,1);
                break;
            }

    return results;
};
//}}}

Again, be careful about non-breaking spaces. Now, how it works. It introduces an "extended" filter syntax: "[tag[smth]] [not[tag[smth else]]" corresponds to tiddlers with the "smth" tag and without "smth else" tag. The whole syntax is this: [not[filterName[filterName argument]], so you can use [not[[TiddlerName]] and others as well.
 

If I understand the point of "describeNode", it is used to trick TW into thinking the content of the include is actually a set of tiddlers, which are therefore made available to be directly included.

No, describeNode is a way to describe TiddlyWikis you include in a flexible way so that you can rename/move them without much harm (only need to change the second parameter of the macro). It provids some simplified methods of using including as well (see docs about TwWeb) and (with the "self" argument) allows to forbid including to TW from itseft.
 

Will the "import: 4" option work as I previously described? I think the only reason I can do it without that option, is that CKeditor is being invoked even when "view" is pressed, and its save is overriding the imported tiddler and making it a real (updated) tiddler. If the option 4 works the same way, but will actually show the "edit" button by default, that would be great. I assume my users are not savvy and don't want to confuse them when it shows view vice edit, but it actually edits in any case.

Well, import:2, import:4 simulate such behaviour. In contrast to including, importing doesn't cause toolbar to show "view" button: it updates actual tiddlers in the including TW (so after they are imported, you can forget about STP). Autoimport imports tiddlers separately from each store and 2 and 4 modes import only newer versions. When you import from each other TW, this results in the most recent one being imported (assuming clocks show the same time in each PC, by the way!).
 

I'll give you a little more background on what I'm doing here. I work is a very locked down workplace. Getting anything approved to be installed requires teeth pulling, and even then, few solutions provide the flexibility that TW does. I need collaboration, as I'm using TW as a knowledgebase. All the TWs reside in a single folder on a network drive. There will be one TW named after each user, plus the source TW maintained by a designated manager.

Looks like all the issues have gone.

Best regards,
Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html#SharedTiddlersPluginCode
[2] http://closure-compiler.appspot.com/home
 

[luca....@gmail.com]

Hi,
 thanks for the beautiful Plugin.
I have a aquestion: it is possible to see images that belongs to tiddler coming from the included files?

Thanks

[Steve Rutter]

Everything should look as it is in the original tiddler, regardless of whether it is an external link or embedded base64 encoding.

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.

[Yakov]

Hi Luca,

пятница, 31 мая 2013 г., 16:13:45 UTC+4 пользователь luca....@gmail.com написал:

Hi,
 thanks for the beautiful Plugin.

you are welcome.
 

I have a aquestion: it is possible to see images that belongs to tiddler coming from the included files?

As for now, there's no dedicated system of handling images, so they should work only if the path inside [img[path]] is absolute or it is relative but both TWs are in the same folder. If the image is actually stored in the tiddler (canvas etc), it should work in any case, although I have no experience in using such things. A couple of mechanisms that will fix the relative addresses problem are planned, but they are a few versions away.

Best regards,
Yakov.

[Yakov]

Hello all,

few more steps forward in STP 2.3.0:

* new import modes (2, import more recent versions, and 3, import on confirm) are implemented
* manual ImportIncluded is made "state-of-art" (supports modes, "node: nodeName" syntax, prevents importing unexisting tiddlers created by the "tiddler" filter etc)
* "import" button is added to the inline-management-of-included-tiddler panel
* propagation for pretty links and image formatters is introduced, meaning that included tiddlers will automatically include tiddlers they reference from the same TW ("reference" here means "reference by pretty links"), and images, inserted into included tiddlers, will be "corrected" so that if one is inserted using a relative path, the path will be recalced "from" the source TW, not "from" the including one

For more details, see docs [1].

Best regards,
Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html#SharedTiddlersPluginInfo

пятница, 31 мая 2013 г., 17:54:33 UTC+4 пользователь Yakov написал:

[Steve Rutter]

Yakov, could you do me a favor and begin attaching your html file to this thread when it is updated? I primarily only reference this thread at work, and your domain is blocked here, so I can't see the new code without pulling it down from home (which I frequently forget to do . . . family and all). Thanks.

--

You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.

Visit this group at http://groups.google.com/group/tiddlywiki.

[Yakov]

Hi Steve,

ok, here it is. Remind me if I forget to attach next times.

Best regards,
Yakov.

среда, 19 июня 2013 г., 9:09:05 UTC+4 пользователь bluespire написал:

[Scott Simmons]

Hi, Yakov —

It took me a while, but I finally got around to updating to the 2.x series, and I have to say:  Your amazing plugin is 50% MORE amazing than it already was!  :D  I'm loving the link to included tiddlers' native TWs and the support of user-defined nodes.

For me, though, setting config.options.STP_hijackImageFormatter to true yields an error message alert every time I load my TW (or a tiddler, even it it's not an included tiddler):

Is it just me?

[Scott Simmons]

I thought the culprit would surely be a plugin (or set of plugins) and did some testing — creating an empty TiddlyWiki with only STP installed and porting over plugins from my main TiddlyWiki one by one.

I was surprised to find I got the same alert notification when using the Backstage's Import Tiddlers mechanism.  For whatever reason, I got 15 consecutive alerts on loading the list of tiddlers from my main TiddlyWiki.

However, I was never able to get the same error on opening tiddlers as I got in my main TiddlyWiki — even after all the plugins were brought over.

If anyone's curious, I've copied my troubleshooting log so you can see it here:

http://tiddlywiki.secret-hq.com/#%5B%5BTiddlyWiki%3A%20SharedTiddlersPlugin%20error%20on%20tiddler%20(or%20TW)%20load%5D%5D

—

I'm also having trouble using the PrettyLink hijacking function.  Maybe there's something wrong with my syntax, or maybe it's somehow related.  (I'm leaning toward my syntax since it happens in an empty TW with only SharedTiddlersPlugin installed.)

Just in case, here's the log on that:

http://tiddlywiki.secret-hq.com/#%5B%5BTiddlyWiki%3A%20SharedTiddlersPlugin%20nodes%20not%20working%5D%5D

[Yakov]

Hi Scott,

понедельник, 12 августа 2013 г., 8:49:24 UTC+4 пользователь Scott Simmons написал:

Hi, Yakov —

It took me a while, but I finally got around to updating to the 2.x series, and I have to say:  Your amazing plugin is 50% MORE amazing than it already was!  :D  I'm loving the link to included tiddlers' native TWs and the support of user-defined nodes.

Thanks. I hope that this year it will become about 50% more cool again :) reloading is on its way, and some other features as well, but the development doesn't go very fast.. may be I even have to redesign some internals once again.

For me, though, setting config.options.STP_hijackImageFormatter to true yields an error message alert every time I load my TW (or a tiddler, even it it's not an included tiddler):

Is it just me?

Ok, I can see where the problem can be from. Try this: grab the full-code version of STP [1] and substitute the line

                includeURL = w.tiddler.getIncludeURL(),

with the line

                includeURL = w.tiddler ? w.tiddler.getIncludeURL() : "",

and let me know the result. Or you can send me a TW you have trouble with to me directly.


As for the trouble with the [[tiddler]]@node syntax, I didn't really get what happens/doesn't happen. May be you can attach a couple of TWs with minimum tiddlers reproducing the problem?
(describeNode macro can be used inline, but I consider that as rather bad practice -- it was introduced in first place to be able to use one nodeName in several places, so the definition should be elsewhere, in IncludeList)

Best regards,
Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html#SharedTiddlersPluginCode

[Scott Simmons]

Thanks. I hope that this year it will become about 50% more cool again :) reloading is on its way, and some other features as well, but the development doesn't go very fast.. may be I even have to redesign some internals once again.

Slow and steady wins the race.  ;)  It's certainly taken me long enough to catch up to you as a user, and I don't mind waiting for updates, especially when the current version suits my needs so well.

 

Ok, I can see where the problem can be from. Try this: grab the full-code version of STP [1] and substitute the line

                includeURL = w.tiddler.getIncludeURL(),

with the line

                includeURL = w.tiddler ? w.tiddler.getIncludeURL() : "",

and let me know the result. Or you can send me a TW you have trouble with to me directly.

That worked beautifully for me at first — until I had multiple TWs with SharedTiddlersPlugin enabled open at the same time.  When that occurs, I get a slightly different alert:

I may have introduced a new bug on my end.  To manage config.options.STP_hijackPrettyLink and config.options.STP_hijackImageFormatter, I created two option checkboxes — chkLetSTPHijackPrettyLinks and chkLetSTPHijackImageFormatter, respectively.  Then I check and set the main values with this line before your code:

config.options.STP_hijackPrettyLink     = config.options.chkLetSTPHijackPrettyLinks;
config.options.STP_hijackImageFormatter = config.options.chkLetSTPHijackImageFormatter;

(The idea was to insulate your values from my cookies so I could turn off or delete my cookies if you used something different later on.  Of course, that introduces the possibility that I've screwed something up.)

Maybe there's a conflict somewhere between the cookies being set by these options?

I'll try overriding them by hard-coding the values for config.options.STP_hijackPrettyLink and config.options.STP_hijackImageFormatter and report back.  (But if anyone spots anything bone-headed about my scheme itself, please chime in and let me know.)

 

As for the trouble with the [[tiddler]]@node syntax, I didn't really get what happens/doesn't happen. May be you can attach a couple of TWs with minimum tiddlers reproducing the problem?
(describeNode macro can be used inline, but I consider that as rather bad practice -- it was introduced in first place to be able to use one nodeName in several places, so the definition should be elsewhere, in IncludeList)

 

In putting together a test case to show you, I saw the problem.  It wasn't my syntax -- but it was some ham-fisted TiddlyWiking on my part.  :(

My inline node definition was enclosed in /% and %/ as part of the definitions of a tab set.  E.g.:

<<tabs txtTabSetTabs "tab1" "first tab" [[ThisTiddler##MyTab]] etc.>>

/%

!MyTab

<<describeNode "nodeName" "index.html">>See [[this link|ThatTiddler]]@nodeName for details.

%/

... which is why I was seeing the error:  The node definition wasn't being set because it was hidden from display and wikification! (When the section it was contained within was displayed in the tab set, the link and text got wikified fine, but the node definition doesn't get wikified in that context and was undefined.  (Hence the error.)

Of course, this is handily avoided by defining all nodes in IncludeList.  :P

[Scott Simmons]

Since the alert is only showing up with ImageFormatter hijacking, I decided to look at PrettyLink hijacking (which never throws an error) and see what the differences were.

The function associated with PrettyLink hijacking allows for null/undefined values:

includeURL = w.tiddler ? w.tiddler.getIncludeURL() : null,

... but the ImageFormatter hijacking function only allows for empty sets:

includeURL = w.tiddler ? w.tiddler.getIncludeURL() : "",

I'm updating that line in the ImageFormatter hijack function to match the one in the PrettyLink hijacking function to see if that does away with the mysterious alert.  :)

[Yakov]

Hi Scott,

пятница, 16 августа 2013 г., 8:28:15 UTC+4 пользователь Scott Simmons написал:

Thanks. I hope that this year it will become about 50% more cool again :) reloading is on its way, and some other features as well, but the development doesn't go very fast.. may be I even have to redesign some internals once again.

Slow and steady wins the race.  ;)  It's certainly taken me long enough to catch up to you as a user, and I don't mind waiting for updates, especially when the current version suits my needs so well.

 

Ok, I can see where the problem can be from. Try this: grab the full-code version of STP [1] and substitute the line

                includeURL = w.tiddler.getIncludeURL(),

with the line

                includeURL = w.tiddler ? w.tiddler.getIncludeURL() : "",

and let me know the result. Or you can send me a TW you have trouble with to me directly.

That worked beautifully for me at first —

Ok, this fix will be included in the next release.
 

until I had multiple TWs with SharedTiddlersPlugin enabled open at the same time.  

As you point that the new alert pops only with ImageFormatter hijacking, the new thing shouldn't be connected with the previous one.
 

When that occurs, I get a slightly different alert:

The alert mention the "search" method; only two functinos in STP use it "explicitly": stp_resolveURL and isRelativeURL, but I don't see those being used in the hijacking. It would be helpful if you try to debug this by adding

try { <stuff with "url.search" part> }
catch(e) { alert(<smth>); }

blocks in those two functions -- this will let us know whether the exceptions occur in those functions or in some code from "outside" of the plugin.

Again, if you attach minimal test TW files to reproduce the problem, I can try to track it myself.
 

I may have introduced a new bug on my end.  To manage config.options.STP_hijackPrettyLink and config.options.STP_hijackImageFormatter, I created two option checkboxes — chkLetSTPHijackPrettyLinks and chkLetSTPHijackImageFormatter, respectively.  Then I check and set the main values with this line before your code:

config.options.STP_hijackPrettyLink     = config.options.chkLetSTPHijackPrettyLinks;
config.options.STP_hijackImageFormatter = config.options.chkLetSTPHijackImageFormatter;

(The idea was to insulate your values from my cookies so I could turn off or delete my cookies if you used something different later on.  Of course, that introduces the possibility that I've screwed something up.)

Maybe there's a conflict somewhere between the cookies being set by these options?

I wouldn't expect any problems merely because of cookies: the config.options.STP_... parameters are only used at startup, so no big deal if they are set randomly.

The null/"" difference should actually make no difference in PrettyLink hijack, too: both versions lead to the same result in includeURL? includeURL : undefined part and includeURL is not used anywhere else in the function..
 

I'll try overriding them by hard-coding the values for config.options.STP_hijackPrettyLink and config.options.STP_hijackImageFormatter and report back.  (But if anyone spots anything bone-headed about my scheme itself, please chime in and let me know.)

 

As for the trouble with the [[tiddler]]@node syntax, I didn't really get what happens/doesn't happen. May be you can attach a couple of TWs with minimum tiddlers reproducing the problem?
(describeNode macro can be used inline, but I consider that as rather bad practice -- it was introduced in first place to be able to use one nodeName in several places, so the definition should be elsewhere, in IncludeList)

 

In putting together a test case to show you, I saw the problem.  It wasn't my syntax -- but it was some ham-fisted TiddlyWiking on my part.  :(

My inline node definition was enclosed in /% and %/ as part of the definitions of a tab set.  E.g.:

<<tabs txtTabSetTabs "tab1" "first tab" [[ThisTiddler##MyTab]] etc.>>

/%

!MyTab

<<describeNode "nodeName" "index.html">>See [[this link|ThatTiddler]]@nodeName for details.

%/

... which is why I was seeing the error:  The node definition wasn't being set because it was hidden from display and wikification! (When the section it was contained within was displayed in the tab set, the link and text got wikified fine, but the node definition doesn't get wikified in that context and was undefined.  (Hence the error.)
 

Of course, this is handily avoided by defining all nodes in IncludeList.  :P

 

Right, so no real problem here. By the way, you can use css to hide inline describeNode macros, but again, that's not how they are intended to be used (so I don't add any "hide" options to them).

I've took a look at your "re-written documentation", perhaps I'll use more tabs in the main documentation, too. At least somewhere "basic/advanced" tabs look quite appropriate. Though, those may complicate the structure of the tiddler code too much. I'll see.

Best regards,
Yakov.

[Scott Simmons]

Thanks for the follow-up, Yakov!  Sorry I haven't been much help this week.  I sent a direct message to you via e-mail, but here's a quick update for anyone watching this thread:

I'm confident the alerts I'm seeing are caused by my own modifications to the plugin — specifically, setting those two values (config.options.STP_hijackPrettyLink and config.options.STP_hijackImageFormatter) via <<chkLetSTPHijackPrettyLinks>> and <<chkLetSTPHijackImageFormatter>>.  Since the problem arises when I have multiple TWs with STP installed open, I must be introducing a conflicting value somewhere -- perhaps when my zOptionsDefaults tiddler (which includes hard-coded overrides for cookie-based settings) is loaded.

In case anyone's curious, there's a minimal test case TW here:

http://tiddlywiki.secret-hq.com/testing/SharedTiddlersPlugin_MysteryAlert.html

(To see the behavior, you may have to download two copies, change the last two checkbox options in STP's Configuration Section, and reload with both copies open in the same browser.)

[Yakov]

Hello there,

the new STP 2.4.0 is released [1]. The main new feature in it is reloading which is done via the reloadIncluded macro.

One way to use it  is inline usage: say, you have some list <<list filter "[tag[ToDo]]">> which brings tiddlers from other TWs as well, so you'll probably change it to

  <<list filter "[tag[ToDo]]">><<reloadIncluded urls:'["url1.html","url2.html","node: nodeName3"]' label:"refresh ToDos">>

where urls describe TWs you want to reload (if omitted, means "reload all"). In this case, you'll get a link right below the list (you can turn it into a standart "button" by adding class:button parameter).

Another way is to create a reloading link in each tiddler. Currently, there's such link in the inline panel (along with the "open in the source TiddlyWiki" and "import" links) in the edit mode, but I'm not very happy with this one: after clicking "refresh", one doesn't get the refresh immediately in the edit mode; instead, one should leave edit mode, accept the "Are you sure you want to abandon your changes to ...?" dialogue and in the view mode the changes will be applied. Anyway, I'll be testing this in real-life TWs (although, the intended usage is via inline macros). You can also play with the ViewTemplate; let me know what you think.

Other changes are:
* new external filter, support of the node: nodeName notation in the includedFrom filter, fixes in the includedFrom and internal filters
* fixed the problem in hijackImageFormatter found together with Scott Simmons (thanks)
* wikifyIncluded macro is completely removed (no notifications are now provided)

Unfortunately, the next version probably won't be released soon, as the need to rewrite a big part of the code is getting more and more pressing. The good news is it will let to implement things like displaying different versions of a tiddler from different TWs simultaneously (well, not as separate tiddlers, but still), make conflict and preferences system simpler, reduce the code size and probably improve performance. But we'll see, there's still many things to implement.

Best regards,
Yakov.

[1] http://yakovl.bplaced.net/TW/STP/STP.html

воскресенье, 16 декабря 2012 г., 2:42:51 UTC+4 пользователь Yakov написал:

Hello everybody,

[Tobias Beer]

Hi Yakov...

Great work, thanks!

Something to perhaps consider: to distinguish between readOnly and editing / admin mode.

For example, in readOnly I would (by default) not want to display a visitor any include messages.

In editing / admin mode, I would want all included tiddlers to be rendered with a given class on top of ".tiddler" and perhaps also with the source as an attribute, e.g. rel="xyz.html". That way, I can style them differently (even by source) and visually see from what source a tiddler is.

These classes could be also available in readOnly mode, but it would perhaps not be desired to apply that styling, so that a visitor to some site wouldn't know anything about inclusion and that stuff.

There could also be some <<include info>> macro that shows include information for the current tiddler... which could be rendered as a panel below the tiddler body.

Perhaps some of these things already exist.

Best wishes, Tobias.

[Yakov]

Hi Tobias,

среда, 11 сентября 2013 г., 18:31:14 UTC+4 пользователь Tobias Beer написал:

Hi Yakov...

Great work, thanks!

You are welcome :)
 

Something to perhaps consider: to distinguish between readOnly and editing / admin mode.

For example, in readOnly I would (by default) not want to display a visitor any include messages.

Well, I wouldn't say that I want such behavior by default (for instance, I'd like to see such messages on my cite, but consider them as "errors to be fixed"), but this can be easily "implemented". As you probably know, there's a global readOnly variable in TiddlyWiki, so you can just write in the "Config" part of the plugin something like:

config.options.chkWarnOnSharedTiddlersConflicts  = readOnly ? fasle : true;
config.options.chkAlertOnSharedTiddlersConflicts = false;
 

In editing / admin mode, I would want all included tiddlers to be rendered with a given class on top of ".tiddler" and perhaps also with the source as an attribute, e.g. rel="xyz.html". That way, I can style them differently (even by source) and visually see from what source a tiddler is.

As for me, I distinguish included tiddlers as they have "view" instead of "edit", but of'course you may want to highlight further. It's may be worth including this into STP itself, but you can solve this by adding a simple plugin:

/***
|Requires|SharedTiddlersPluginDev|
***/
//{{{
config.extensions.SharedTiddlersPlugin.orig_displayTiddler = Story.prototype.displayTiddler;

Story.prototype.displayTiddler = function(srcElement,tiddler,template,animate,unused,customFields,toggle,animationSrc) {

    var tiddlerElem = config.extensions.SharedTiddlersPlugin.orig_displayTiddler.apply(this,arguments);

    var title = (tiddler instanceof Tiddler) ? tiddler.title : tiddler,
        tid = store.fetchTiddler(title);

    if(tid && tiddlerElem)
        if(tid.getIncludeURL())
            jQuery(tiddlerElem).addClass("included");

    return tiddlerElem;
}
//}}}

It adds the desirable "included" class.
 

These classes could be also available in readOnly mode, but it would perhaps not be desired to apply that styling, so that a visitor to some site wouldn't know anything about inclusion and that stuff.

Well, I'd say that applying the styles themseflves is not the work of STP anyway (one would prefer to change the background color, another -- something else), so you can apply them using a microplugin which checks the readOnly variable and desides whether to apply.
 

There could also be some <<include info>> macro that shows include information for the current tiddler... which could be rendered as a panel below the tiddler body.

I'm thinking about this: I'd prefer something like ", included from .... (refresh)" (where "refresh" is the output of the <<reloadIncluded>> macro), but it seems that this can't be hijacked elegantly. Of'course one can hijack the view macro like it's done to the edit macro already and add the desirable info/macros, but simple options (add before or after the viewer area) don't look very nice. May be adding toolbar commands would be better, but I still haven't learned how to use the popup interface, especially in the toolbar. What do you think?
 
Best regards,
Yakov.

PS by the way, it seems that STP is not present in the customize space you introduced recently. What's the main method to add changes to the space? 

[Tobias Beer]

I'm thinking about this: I'd prefer something like ", included from .... (refresh)" (where "refresh" is the output of the <<reloadIncluded>> macro), but it seems that this can't be hijacked elegantly. Of'course one can hijack the view macro like it's done to the edit macro already and add the desirable info/macros, but simple options (add before or after the viewer area) don't look very nice. May be adding toolbar commands would be better, but I still haven't learned how to use the popup interface, especially in the toolbar. What do you think?

Personally, I think a simple macro call I add to the ViewTemplate wherever I like is just fine.

Perhaps it would only render anything show when a tiddler is actually included.

If you ask me, there's no need for popups. They can even be CSS only, or added before or inside the toolbar div as a pseudo-toolbar button. No need for a bunch of code for "the real deal", imho. If you want that, just take a look at how some core toolbar buttons are implemented.

To me it's as simple as...

<<include info>>

or...

<div class="include-info-wrapper" macro="include info"></div>

• outputs info when actually included
  
• using something like config.macros.include.fmtInfo.format([detail1, detail2, detail3]);
• styling => css

Seeing your example macro for the css stuff above, especially getIncludeURL the this can be easily done then in a bout 10 minutes ;-)

Best wishes, Tobias.