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). On Thu, May 30, 2013 at 5:19 AM, Yakov <[email protected]>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]. > 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. > > > -- 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.
