Been trying to get around to replying... On May 23, 10:52 pm, "[email protected]" <[email protected]> wrote: >By the way, if you haven't already done it, it's probably best to make >your fork for tiddlyweb-plugins have tiddlyweb/tiddlyweb-plugins as >its upstream, not cdent/tididlyweb-plugins.
Yea I later realized most of the commit activity is in tiddlyweb/ tiddlyweb-plugins. Is cdent/tiddlyweb mainly for releases? > This is a very useful filter, for a variety of things. It will be > handy for abstracting a lot of duplicated code in some of the plugins > that already exist. One point about this filter (which I clumsily attempted to explain in the readme). The filter interface basically says that filters only know about one tiddler at a time. The tiddlylinkfilter has an extra requirement due to the initial step of accessing the store to pick up the condition tiddler. The way this is currently done is kind of hacky, and runs into trouble in a special case. There's a potential problem when the filter is applied to recipes that have multiple copies of the condition tiddler. If I understand correctly, when there are multiple copies of a tiddler in the list of bags making a recipe, the recipe uses whichever one appears in the later bag. To give the right results the tiddlylinkfilter should use the same condition tiddler used in the recipe after it is 'uniquified', but as far as I can see, to do that requires knowing the bags used by the recipe (and the order they occur in). > > Well that's about it. I'm running this setup right now and noting > > problems that come up. This is just experimental and of course doesn't > > solve any other issues like handling of searches, but it provides a > > pretty good way of further testing a load on demand setup. > > How's it working out so far? Any surprises? It does a decent job fulfilling the basic on demand loading requirement. I'm finding the lack of a complete timeline and taglist to be kind of inconvenient. Also because of the flexibility in styling TiddlyWikis, the initial tiddlers that need to be available can vary a lot. I think skinny tiddlers / lazy loading will prove to be a more useful approach in most cases. I've been kicking around some ideas...I'll post an outline of that in a bit. I'd like to work out a skinny tiddler solution with you guys, and then focus on the plugin and search issues. I have a feeling that dealing with skinny tiddlers is going to require dipping into TiddlyWiki's core at a fairly basic level. > It's really great to see you doing this work. I'm especially glad that > you've posted up the code so people can have a poke themselves. > > The way you've created your plugins is cool to see and really shows > off some of the flexibility I hoped, but wasn't sure, that I was > building into the system. The design of TiddlyWeb is really impressive. You've done a remarkable job in making virtually every component extensible. Combined with the extensibility of TiddlyWiki itself the possibilities are mind boggling. > You've made your plugins in a way that is > almost entirely different from how I would do it, but in a perfectly > reasonable and potentially better way. I'm very curious how you might have made the plugins. What I ended up with was not really what I expected at the outset. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
