> Yeah, that's perniciously hard to reliably parse for both a person (at > least this) and a computer, and it couples into the same engine three > very different pieces of functionality. That coupling is what you > might call anathema to the TiddlyWebWay™.
I think that part of the dissonance is that the TiddlyWiki filter syntax is intentionally wiki-ish, while the TiddlyWeb design is being drawn more towards URI-ishness. And URI-ness intentionally beats wiki-ness for TiddlyWeb, I think. Originally, I was attracted to a common syntax for the client and the server because it makes it easier to offload client-side work to the server, but, I guess the ability to convert between the two different syntaxes would be OK. I'm wondering if we exploit the idea of the same bag being listed in the same recipe multiple times we can't make the syntax substantially simpler? The best syntax would surely be almost no syntax at all :) Cheers Jeremy > As things currently stand filters in TiddlyWeb are though of as a > single query parameter on a URL (?filter=<the filter string>). Better > I think would be (at least) three: > > * select or filter for things like <fieldname>:<fieldspec (include > simple regular expressions)> > * sort > * limit or count (can't decide if this would be just a number of would > have some kind of spec to) > > Then you can parse the query string, and have specific bits of code > that select, sort or limit do what they do best, rather than a > monolith that is confusing. > > Set handling could be done as follows (I'm making this up as I go, so > please suggest something else if this seems wack): > > * Unions: use multiple select query paramters, each parameter does > another select on the full set of tiddlers are the collection being > filtered/selected from: eg select=tag:blog&select=tag:coment gets all > tiddlers tagged blog plus all tiddlers tagged comment. > * Intersections: multiple selection statements in one select paramter: > select=tag:blog%20tag:comment gets only those tiddlers that are tagged > both tag and comment. > > (One reason I like this idea is that I find it easy to imagine the > solution: it is still based on generating functions from parsing the > query string: tag:blog leads to a particular function, whether it is > doing an intersection or union is based on which set of tiddlers are > fed to it.) > > Obviously someone can come up with some case that this syntax will not > satisfy but we can do that all day and night, with any syntax. No > syntax will be perfect. Sometimes you just have to say, "you can't do > that with this, you'll need to do your own thing." > > Some of the shortcomings in this syntax can be overcome by having the > same bag listed in one recipe multiple times and filtering the output > of the entire recipe (this is already the common way to create a > recent changes syndication feed). > > Comments? > > > -- Jeremy Ruston mailto:[email protected] http://www.tiddlywiki.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
