I have a plugin that defines parametrized tiddlers as components, there is 
a demo here:

http://components.tiddlyspot.com/

The demo overrides the implementation of the tabs macro as an example.

BJ

On Wednesday, January 3, 2018 at 8:01:05 AM UTC+1, Evan Balster wrote:
>
> Hey, all —
>
> A while ago I noticed Jeremy expressing some regrets about how TiddlyWiki 
> has become dependent on text substitution macros, and suggesting that TWX 
> will do something differently:
>
> *Jeremy Ruston:*
>
> Thus, there are lots of quite prominent features that were introduced 
>> early on and that I would now handle differently (eg, the fact there is a 
>> difference between transclusion and the view widget, or the presence of 
>> text substitution macros which I now think was a mistake).
>>
>
> Having developed a lot of things in TW *and* reviewed the widget 
> architecture with an eye for performance, I have to agree.  People across 
> the experience gamut seem to routinely stumble on the order-of-operations 
> involved in parsing widgets and expanding macros.  I'm also speaking as a 
> compiler-designer:  I've made the mistake of letting macros stand in for 
> functions in a language I've designed, and it was a problem for both 
> maintainability and performance.
>
> I view TiddlyWiki as a functional programming system, where each widget is 
> a node with some parameters (attributes, parse tree / children) and a 
> result (DOM tree).  Macros are the de-facto stand in for programmable 
> subroutines, but they are unstructured and must be re-parsed whenever they 
> appear.  Transcluded tiddlers may also behave like subroutines, and while 
> they're structured they don't support explicit parameters.
>
>
> The solution I anticipate would be to introduce a "wiki-function" entity 
> which is pre-parsed and whose invocation does nothing more than set a few 
> variables and instantiate its parse tree into widgets.  Perhaps something 
> like this, widget-wise, with a WikiText syntax to get rid of the 
> boilerplate:
>
> <$function $name="tablerows" filter>
>     <$list filter=<<filter>> >
>         <tr>
>             <th>{{!!title}}</th>
>             <td>{{!!field1}}</td>
>             <td>{{!!field2}}</td>
>         </tr>
>     </$list>
> </$function>
>
>
> <table>
>     <tr>
>         <th>Title</th>
>         <th>field1</th>
>         <th>field2</th>
>     </tr>
> <tr><th colspan=3>Important Stuff</th></tr>
>     <$call $name="tablerows" filter="[tag[Tag1]tag[Important]]" />
> <tr><th colspan=3>Less-Important Stuff</th></tr>
>     <$call $name="tablerows" filter="[tag[Tag1]!tag[Important]]" />
> </table>
>
> Now, this *does* look basically the same as a macro call.  The 
> differences are crucial, though: lower parsing and refresh overhead, only 
> <<one syntax>> for variables, and no gotchas with quoting, whitespace, 
> order-of-operations or open markup.  As far as I'm concerned, the 
> similarity in usage could make transitioning trivial in many cases and the 
> more consistent behavior could make TiddlyWiki "programming" much easier to 
> learn.
>

-- 
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 https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/962d34c7-dcf7-41bd-82f9-84332bc463e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to