Hi Tobias, > Wouldn't you rather have to loop over all tiddlers and remove those > from the store that are not in the resulting filtered list?
Well, it seems that it should work slower because core filters return an array of tiddlers, so to remove unnecessary ones I should make a double cycle (for each tiddler check if it doesn't coinside with any of those filtered ones). > Haven't yet looked at filterTiddlers, but why not just make > a clone of it, call it 'removeByFilter' and instead of adding matching > tiddlers to some result list, directly remove from a given store > those that do NOT match the filter criteria? Each filter returns a set of tiddler and filterTiddlers uses this, so this is an implementation issue. I can create "removeByFilter" but it will also use this double cycle. Well, perhaps that's not that bad.. for smaller TWs (and IncludePlugin can be used to make them smaller). > I'm not sure though about the right method > to remove a tiddler from an included store. @Dev team: need help :) > In fact, I believe I would not use filers at all but rather use > variables to define... > - exludeTags > - overrideExcludeTags (in order to keep sth. nonetheless) > ...and then hijack or even modify the inclusion method to directly not > even import those unwanted tiddlers, instead of removing them > afterwards. > > Haven't we already had this discussion or was I just dreaming? Yes, I've implemented the extension of the plugin that way, but I feel like fiters are more suitable, because: 1. they are extensible and one wouldn't have to change the IncludePlugin 2. I just like the idea of filters very much and I had a similar idea (called "aggregated sets") before I found them in discussions. It's just a very proper tool for aggregation, although I need more filters than the core provide. 3. an array of core filters (as a "filtering structure") would work more adequate to usage of multiple Include macros: implementation with "hand-made" filters would be more bulky (in the code) and hijacked fetchTiddler will work much slower if multiple Include macros are used. In fact this latter issue is directly connected to the changing of stores: I can either change stores (so this addition of filters (sets to include) is computed once) or change the hijacked fetchTiddler behavior -- so this computation is done each time fetchTiddler is used (for included tiddlers). On the other hand, multiple use of Include macros is natural to implement OR, while AND can be "easily" implemented by core filters (add andIsTagged filter for "and has .. tag" etc). Regards, Yakov. -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
