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
> 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).
>
> On Thu, May 30, 2013 at 5:19 AM, Yakov <[email protected]<javascript:>
> > wrote:
>
>> 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 написал:
>>>
>>> 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.
>>>
>>> On Wed, May 29, 2013 at 5:45 PM, Yakov <yakov.litv...@gmail.**com>wrote:
>>>
>>>> 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).
>>>>
>>>>
>>>> воскресенье, 16 декабря 2012 г., 2:42:51 UTC+4 пользователь 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/**S**TP/STP.html<http://yakovl.bplaced.net/TW/STP/STP.html>
>>>>> [2] http://www.tiddlytools.com/#**To**ggleLeftSidebar%**20ToggleRightS
>>>>> **idebar<http://www.tiddlytools.com/#ToggleLeftSidebar%20ToggleRightSidebar>
>>>>>
>>>>> [3]
>>>>> http://tiddlywiki.abego-**softwa**re.de/#IncludePlugin<http://tiddlywiki.abego-software.de/#IncludePlugin>
>>>>>
>>>> --
>>>> 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 [email protected].
>>>> Visit this group at
>>>> http://groups.google.com/**group/tiddlywiki?hl=en<http://groups.google.com/group/tiddlywiki?hl=en>
>>>> .
>>>> For more options, visit
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>>
>>> --
>> 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 [email protected] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
