I've been wanting to release a 1.0 version of TiddlyWeb for some time now, but there continue to be a few issues which may or may not need to be addressed before such a thing can happen:
* filters * server side validation * something I can't remember now (feel free to point things out) In this message I'd like to discuss filters. In the original design discussions surrounding what eventually became TiddlyWeb, filters were created as a syntax for selecting a subset of tiddlers from a bag listed in a recipe. A recipe would list several bags, and filters would limit the tiddlers pulled from the bags. A TiddlyWeb evolved, it became clear that a filter could be used on any collection of tiddlers: a bag, the list of tiddlers made from a recipe, etc. So that's how things are now. The name "filter" and the syntax used comes from TiddlyWiki filters, used in the <<list>> macro. However the implementation is not exactly the same and therein lies the rub, the issue, and the question. The name and similarity in syntax leads people to think that the implementation and results will be the same as when using TiddlyWiki filters. It's not. This issue has been known for some time but nothing done about it in the hope that some filter use cases would accumulate and from those a decision could be made about how best to "fix" filters in TiddlyWeb. TiddlyWeb has had a fairly significant number of downloads, and I've had reports from a fair few people about what they are up to, but the filter use cases have not accumulated. Please take this message as a (verbose) invitation to provide them. There seems to be a few different ways forward (some of these might be combined): 1. Carry on with filters as they are now and let them evolve as requirements are revealed. 2. Rename TiddlyWeb filters to something else, to distinguish them from TiddlyWiki filters. 3. Make TiddlyWeb filters act exactly the same as TiddlyWiki filters. 4. Create something new and better that is specific for the TiddlyWeb setting. 4 is of interest to me (as opposed to 3) because I think the bags with filters in recipes use case is not the same as the <<list>> macro use case in TiddlyWiki. The former is kind of a selector, while the latter is effectively a filter. 3 is not as easy as you might think at first glance. It would be possible to port the TiddlyWiki filter Javascript to Python and carry on from there, but it would be a deep chance to how filters currently work in TiddlyWeb. I feel this way of working is a good thing (in fact I think TiddlyWiki would benefit from using it). Last I checked, in TiddlyWiki a regular expression parses the filter string and while this filter string is being parsed a results list of filtered/found tiddlers is created and extended. In TiddlyWeb the filter string is parsed to a list of filter functions. After the parsing those filter functions are applied to the collection of tiddlers being filtered. This separation of parsing and filtering means that the filtering mechanism is easy to extend without having to invade the core filter code. This a patently good thing. The couple of times I've given it a brief effort I've found myself too stupid or too discouraged to port the TiddlyWiki filter handling to TiddlyWeb while still preserving the function compilation process that TiddlyWeb uses, so I've stalled out. Assistance most welcome! 2 is growing in my mind as the right thing to do. Filters as currently implemented meld several concepts that are quite distinct into one mechanism and I think is probably bad for future easy development. Filters are used to both get a limited set of tiddlers as well as to sort tiddlers. Better to have things which limit and things which sort: limiters and sorters. There may be others things as well. 1 might be acceptable except that there are some significant problems with the current implementation. The most notable is that in one filter string, two filters result in a union of the found tiddlers, not the intersection. So if you: /bags/system/tiddlers?filter=[tag[systemConfig]][tag[foobar]] you get all the tiddlers that are tagged systemConfig and all the tiddlers that are tagged foobar. This doesn't seem aligned with the intent, especially since it is possible to get that result, in a recipe, by listing the same bag twice: /bags/system/tiddlers?filter=[tag[foobar]] /bags/system/tiddlers?filter=[tag[systemConfig]] My conclusion from this is that some kind of change needs to happen. My inclination is to experiment with something new (thus option 4) but I'm willing to consider option 3 if we can come up with a way to code it cleanly. I'd: * rather not make this decision unilaterally * prefer to make the decision before a 1.0 so that the big changes that will happen still fall under the (vaguely meaningless) umbrella of "alpha" or "beta" Thank you for your input. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to TiddlyWikiDev@googlegroups.com To unsubscribe from this group, send email to tiddlywikidev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
