Mario
Thanks for your knowledgeable response. I have placed some question inline
with your comments. This will be a good opportunity to write some guidance
for others,
I think it depends, what your macros do. .. Eg. If they define global
> functionality, which is useful for every "user" tiddler, or used in the
> ViewTemplate, you pretty much have to make them global, tagging them
> $:/tags/Macro
>
Yes, its learning how to decide with each macro developed how best to
implement it.
If you use them in something like a Dashboard tiddler, it can make sense,
> to \import them in the Dashboard itself. .. It limits the scope of the
> macros, so you won't have problems with "name collisions", which can be an
> issue for global macros.
>
Good example,
>
> There are some differences in macro/variable lookup performance, but I
> think you can safely ignore them. If your application uses a filter
> somewhere, they will outweigh the js macro/variable lookup by far. JS
> variable lookup is highly optimized by browsers.
>
Good to know, this suggests to me that the most important need is self
documentation and ease of lookup and use, rather than being concerned with
performance.
>
> -------------
>
> I personally have several macro definitions in 1 tiddler. IMO this makes
> debugging much easier. It also makes it easier to convert a macro
> definition tiddler into a template, which isn't tagged or imported at, but
> transcluded.
>
I would love an example of this if possible. That is convert a macro
definition tiddler into a template.
>
> Transcluding macros uses more memory, since every transclusion defines new
> macro variables. Calling those macros = variables, has a very minimal
> performance advantage, since the variable lookup is faster. ... BUT every
> transclusion needs time to build those variables. ... So in the end the
> penalties will compensate the advantages.
>
Very important to know. So transclusion redefines, import variables makes
the variables available, $:/tags/Macro makes them always available ?
>
> Global macros are imported in $:/core/ui/PageTemplate ... So those
> variables will only be built, if the page template or one of the macros are
> changed.
>
So this makes them quite efficient, but some of my macros refer to another
value eg
\define wiki-mode() {{$:/config/wiki-mode}}
so will all the the page macros be built every time $:/config/wiki-mode
changes.
>
> $:/tags/Macro/View variables will be built everytime the ViewTemplate is
> shown. On the other hand you can use the same macro name per tiddler view.
> This gives you the possibility to change macro behavior per tiddler view in
> the story river.
>
> So again ... It depends, on what you want to do. ...
>
The word "reusability" comes to mind here as a design consideration for
macros.
>
> I think $:/tags/Macro/View is only needed for very special cases. I would
> go with a global macro definition. It makes them simple to use.
>
> -------------
>
Thanks so much for this advice, I almost started using it wholesale, I will
not now.
>
> Having every macro in 1 tiddler can improve the possibility to document
> them. The text below a macro definitions is ignored by the \import process.
> So it doesn't have any memory or performance penalty if there is a lot of
> text there.
>
But .. I personally think, it makes debugging more complex.
Good to know, So If I placed in the body macro documentation is will be
visible on the macro tiddler but not add too much to slow down?
For example?
\define first-tiddler(filter:"[tag<currentTiddler>]") {{{ $filter$ +[first
[]] }}}
\define last-tiddler(filter:"[tag<currentTiddler>]") {{{ $filter$ +[last[]]
}}}
\define next-tiddler(filter:"[tag<currentTiddler>]") {{{ $filter$ +[after[]]
}}}
\define prev-tiddler(filter:"[tag<currentTiddler>]") {{{ $filter$ +[before
[]] }}}
<h2>Macro definition tiddler</h2>
;Obtain the first/last/next/prev member in a list defined by filter
:Defaults to tiddlers tagged with the current tiddler,
`[tag<currentTiddler>]`
*`<<first-tiddler [filter]>>`
*`<<last-tiddler [filter]>>`
*`<<next-tiddler [filter]>>`
*`<<prev-tiddler [filter]>>`
<!-- comment here ok? search keywords etc... -->
>
>
> Adding comments like <!-- comment --> inside the macro body, _will_
> negatively impact macro performance, since the comment is processed
> everytime the macro is executed. (... we should try to improve this )
>
But if I understand correctly it is ok as in the example above?
>
> The [tag[abcd]] filter index does speed up finding tiddlers tagged "abcd"
> quite a bit. So yes. \import filter is improved since the indexing exists.
>
This is when the filters are used in the import widget and pragma
<https://tiddlywiki.com/#ImportVariablesWidget>?
Thanks for this feedback. I will summarise it all at the end of this thread.
Regards
tony
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/fca03fbd-6cb8-48b7-b51f-4d3b1a8eaa16%40googlegroups.com.
