Eric, you're seeing this as someone who can whip up a special filter any time you need one. For the rest of us, how to make a filter isn't even documented. This isn't a one time problem that Mat has with his particular use case, it's a problem that comes up over and over whenever any one tries to push the boundaries even slightly. For instance, AFAIK, there is no filter for comparison operations. Reporting on tiddlers that are newer than some arbitrary date, or that have an indexed field greater some number would be useful in many situations. I put out a request for such a filter in July 2015 and there was interest ... but no follow up. I don't want to nag anyone -- I want to be able to roll my own solutions like it was possible with your InlineJavascriptPlugin.
Thanks! Mark On Sunday, February 28, 2016 at 8:31:25 PM UTC-8, Eric Shulman wrote: > > On Sunday, February 28, 2016 at 2:31:47 PM UTC-8, Mat wrote: >> >> Eric - thank you for a very informative and 'solving' reply! :-) >> ... >> It is depressing to realize that this basic problem is something that >> requires special js code and I therefore simply *cannot* solve myself >> (and this after hours and hours of trying different circumventions). >> > > It's not really "special js code". The <$count> widget has much more > involved js code than this tiny filter does.... and certainly less code > than would be needed to extend the core macro processing to "evaluate" the > macro output and extract a return value from the result. You should think > of the "count" filter as merely an add-on enhancement to the set of filters > you have available. > > The real problem you encountered is that the "count" filter isn't in the > standard core set of filters, so you were looking for a workaround based on > re-purposing existing features (i.e., the $count widget). However, I think > what you are trying to "kill a fly with a sledgehammer." You are proposing > that we radically extend the purpose and behavior of the macro mechanism on > a system-wide basis, just so you can re-use an existing widget in a way > that widgets aren't intended to be used. > > I'm also wondering how such an extended macro processor would handle > refresh events? To "evaluate and return" macro content, the core > processing would need to generate a separate, temporary parse tree for the > macro content (after substitution of params and variables), extract the > "output value" from the tree and then discard the parse tree before > returning the extracted content. The problem here is that without > preserving the parse tree, there's no way to know that there are widgets > *inside* the macro that need to be refreshed. > > In my opinion, this entire approach seems like it would be a "can of > worms", creating more problems than it solves. > > -e > -- 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 https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c08f2b72-a842-466f-8857-9a56e664ef9b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
