Sorry to be late to this discussion.
1. I'm interested in extending (and documenting) the current filter syntax
to cover more use cases. During the beta we can tolerate mild backwards
incompatibility, but the ship has already sailed over the general format of
filters
2. Like Michael, I don't want to see the filter syntax get much more
complicated; as it approaches JavaScript levels of complexity it would make
more sense to let users access JavaScript directly
3. I'm also interested in completely new filter languages. Like Stephan,
I'm interested in Lisp. So, I think it would be useful to define a syntax
for specifying the language used in a filter.
For 3, we could have an optional type marker at the start of the filter
string. For example:
<tw>: [tag[Jeremy]tag[oldschool]]
Or
<lisp>: ((((((lisp code here)))))
<js>: return wiki.getTiddlerList("myList");
4. I worry about the safety of JavaScript embedded directly in wikitext.
I'm hoping to use something like this to be able to have the option of
running JS properly sandboxed:
https://neil.fraser.name/news/2013/12/05/
Best wishes
Jeremy
On Sun, Dec 15, 2013 at 8:08 AM, Michael Herrmann
<[email protected]>wrote:
> Hallo Stephan and all,
>
> I would like to share some basic considerations regarding user interface
> via dedicated wiki language features vs. using JavaScript directly.
>
> - From my point of view there is a risk to provide TW features via a
> new, dedicated syntax that is only slightly shorter and slightly easier
> than JavaScript itself. ( as mentioned above )
> - When this happens, then we loose in many aspects:
> - The code grows.
> - Maintainability decreases.
> - We have to learn something completely new (compared to some
> established technology like JS).
> - On the other hand when the
> *user-recognizable-complexity-distance*between JS syntax plus context
> requirements and a dedicated syntax is high
> enough, then this pays off a lot. For sure.
> - Keeping a good ratio should never be forgotten.
>
> But there's more to it:
>
> - I would think of myself as some kind of intermediate user: I am far
> from understanding the inner workings of TW5. But I do not fear to write a
> couple of statements in JS.
> - In fact, Jeremy can never foresee all the use cases that come to our
> minds. So he will never provide mechanisms for everything.
> - There will always be people like me, who want to make use of TW in
> an unforeseen way.
> - From that point of view, I even prefer a well documented and easy to
> use JS interface.
> - Of course, those intermediate users are a subset of all the users.
> - The real power users, like Stephan, Mario and others have no real
> problem.
> - But there are also the beginners.
> - Perhaps the following principle would help us all:
> - Whenever things become more complex, let's find an easy and well
> documented JS interface.
> - Now that we have a clear plugin mechanism, we can add dedicated
> syntax plugins for those situations that are too much for total
> beginners.
> - Then everyone can choose between both. Advanced users can even
> exclude those beginner's-helper-plugins.
>
> As a summary I clearly vote for not excluding JS as interface in all
> situations.
>
> Regarding list/filter/template context: For me, this is an example where I
> could imagine a JS interface that should not be too complex compared to the
> current syntax.
>
> best regards
> Michael
>
>
>
> Am Freitag, 13. Dezember 2013 20:43:30 UTC+1 schrieb Stephan Hradek:
>
>>
>> I think, we don't need a new filter syntax. We need better documentation
>>> for the existion one.
>>>
>>
>> We need enhancements for the existing one. Tell me how to filter for one
>> of the custom fields I called "is", "sort", "links", "prefix"…
>>
>>
>>
>>> Atm it is one page [1] TiddlerFilters.
>>>
>>
>> But here I agree… The documentation needs enhancement.
>>
>>
>>
>>> The filter syntax parser may need some adjustments too, to make
>>> everything consistent. eg: whitespace for readability should not disable
>>> the filter function.
>>>
>>
>> I also agree here.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "TiddlyWikiDev" 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 http://groups.google.com/group/tiddlywikidev.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Jeremy Ruston
mailto:[email protected]
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" 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 http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/groups/opt_out.
