Hi, so actually the answer is probably not going to be much longer it just contains a macro example and an explanation of how it works. The macro itself can live in any tiddler tagged with $:/tags/Macro.
So first here is the actual macro:
\define RenderContent(id)
<$vars purpose={{{[has[purpose]get[purpose]]}}} id="$id$">
<$list filter="[!has[draft.of]field:tiddler-id<id>field:context<purpose>]">
<$transclude tiddler=<<currentTiddler>> mode="block"/>
</$list>
</$vars>
\end
And while it is a more configureable version of my former solution here is
a breakdown of how it works
- First the macro sets two variables: Purpose via an inline filter and
id which it gets from the macro parameter. For the inline filter all it
does is looking for a tiddler with the field purpose and then gets this
fields value. This stops the reliance on title, but you will have to ensure
that there is always only one purpose field within the wiki.
- The list filter then looks for a tiddler that is not currently being
in editmode - the !has[draft.of] part - and has two fields matching the
values from the variables. For one the context field being the same as
whatever is currently in purpose and the tiddler-id field being the same as
the id passed to the macro.
- When a tiddler fullfilling these conditions is found it is transcluded
at the place the macro was called from.
To use the macro here is an example using Contents, but it is the exact
same process for Title, Subtitle, every future tiddler having different
text depending on context just with a different id.
- In the Contents tiddler you replace your line with the two
transclusions with <<RenderContent "Contents">>.
- In Contents (Product Reviews) you add two fields. One is called
context and has a value of ProductReviews the other is called tiddler-id
and gets a value of Contents.
- In Contents (Urban Off Gridding) the same two fields are added, just
that context now has a value of OffGridding.
That's it, nothing changes visually, but if you decide that Contents -
Product Reviews is a better title for instance the macro still works as
expected.
Since I worked with a local copy of your wiki to ensure that the macro is
working as intended with the wiki it is inteded for I attached a json file
containing the ten tiddlers - the macro itself plus the changed versions of
Contents, Title, Subtitle - that you can just import and everything is set
up as I described above should you prefer this route.
Kind Regards,
Felicia
On Monday, 14 September 2020 04:00:09 UTC+2, Felicia Crow wrote:
>
> Seeing how I may should eventually remember that sleeping at night is a
> thing a short answer for now, but I will return with a longer answer and
> possible examples later.
>
> The solution was mostly to keep it within the current framework and not
> changing too much around. For a more centralised approach to the whole
> system tags and or fields will probably get a more prominent role, both for
> minimizing code duplication as well as dropping a reliance on titles.
> For instance the Content and Title tiddler could call the same macro with
> their type - content and title respectively in this case - and the macro
> filters for a tiddler with two fields: one named tiddler-type matching what
> was send to the macro and the other named context matching the context
> currently in your purpose field. Since this match is made via the two
> fields the title also doesn't matter. This tiddler or more correctly its
> title is returned to the tiddler which then transcludes the result.
>
> I will write a more concrete example when my brain isn't on standby but
> actually working again, but I hope that this may give you some idea already.
>
>
>
> On Monday, 14 September 2020 02:58:31 UTC+2, Charlie Veniot wrote:
>>
>> That looks A-1 to do on one tiddler needing to decide what content to
>> show based on context, but how to do that once so that it can be used for a
>> plethora of tiddlers that show different content based on context?
>>
>> I would not want to put that kind of code on each of my
>> multi-context-handling tiddlers.
>>
>> For that code to exist generically once, I imagine each
>> multi-context-tiddler would need some kind of macro call like:
>> <<SetContextContent "Product Reviews Tiddler Name" "Urban Off Gridding
>> Tiddler Name">>
>>
>> Aside from not doing that myself (for lack of macro and filter
>> knowledge), I didn't want to go there because I often get tripped up
>> setting these things up to not get screwed up every time I change tiddler
>> titles (which I do repeatedly trying to get titles juuuuuust right.)
>>
>> Thoughts? (i.e. how to do that so that both "Contents" tiddler and
>> "Title" tiddler can call some macro that does what your code does, but
>> works generically for every tiddler that needs it?)
>>
>> On Sunday, September 13, 2020 at 9:22:13 PM UTC-3, Felicia Crow wrote:
>>>
>>> Charlie,
>>>
>>> so first things first here is my version. This specific code would go
>>> into Content, but it would look nearly the same with the other tiddlers.
>>>
>>
>>> <$set name="purpose" filter="[[Alternate TiddlyWiki
>>> Purposes]get[purpose]]">
>>> <$list filter="[<purpose>match[ProductReviews]]">
>>> {{Contents (Product Reviews)}}
>>> </$list>
>>> <$list filter="[<purpose>match[OffGridding]]">
>>> {{Contents (Urban Off Gridding)}}
>>> </$list>
>>> </$set>
>>>
>>> As for the explanation:
>>>
>>> - The filter within set gets the current value of the purpose field
>>> that is in the tiddler with the title Alternate TiddlyWiki Purposes.
>>> - The filter in the list widget takes whatever was saved in set and
>>> compares it to the parameter in match. If it matches the list widgets
>>> content will be rendered.
>>>
>>>
>>> The code in itself does pretty much the same as your two transclusion
>>> templates just in one place, so I think it mostly comes down to personal
>>> preference where you check what actually needs to be rendered.
>>>
>>> The only thing I could think of what this solution currently does better
>>> is being more failsafe in its execusion. The way the transclusion tiddlers
>>> in your version are written they only look for fields named purpose which
>>> contains their respective value, so when one adds a field purpose to
>>> another tiddler and gives it the opposite value both versions will be
>>> rendered at the same time. Since this is a wiki only edited by you this
>>> probably won't happen, just realized it when I looked once more at your
>>> templates while I wrote down my version.
>>>
>>> Felicia
>>>
>>>
>>> On Monday, 14 September 2020 01:23:18 UTC+2, Charlie Veniot wrote:
>>>>
>>>> G'day Felicia,
>>>>
>>>> Sure, I'd love to see how you'd go about it.
>>>>
>>>> Since there are always multiple ways of doing things, if you have the
>>>> time: quick thoughts on advantages/disadvantages of both for a quick back
>>>> and forth about them? Might be a pretty short back and forth: I don't
>>>> have
>>>> enough know-how to pickout the "pitfalls" (or "trappings") of various
>>>> approaches?
>>>>
>>>> That aside: I'm kind of proud to have figured out a little something
>>>> about filters in my last post
>>>> <https://groups.google.com/g/tiddlywiki/c/ItNqeGWYX7Q>.
>>>>
>>>> On Sunday, September 13, 2020 at 6:03:04 PM UTC-3, Felicia Crow wrote:
>>>>>
>>>>> Hi Charlie,
>>>>>
>>>>> yes that was what I meant. I always find it interesting to learn the
>>>>> thought process behind someones solution, since it often gives a
>>>>> different
>>>>> perspective on things that I would not have considered before, leads to
>>>>> learning something new or both. So when I saw a solution I would not have
>>>>> thought of myself I was curious how this came to be.
>>>>>
>>>>> I sadly don't have any real tips for learning filters as it is one of
>>>>> the things my brain was actually willing to learn at least the basics
>>>>> quite
>>>>> quickly, but if you want I could write up the solution I had in mind so
>>>>> that you can play around with it, if this would be something that
>>>>> interests
>>>>> you/could help you.
>>>>>
>>>>> And to add something useful to the babbling at the top: A short
>>>>> excursion about the difference between non-javascript and javascript
>>>>> macros
>>>>> at least as far as I learned it - definitely not an expert.
>>>>>
>>>>>
>>>>> - Javascript macros are loaded in with everything else javascript
>>>>> before any processing happens as this is so to speak the engine on
>>>>> which
>>>>> everything runs, so yes a javascript macro is already loaded in when
>>>>> the
>>>>> startup actions are run.
>>>>> - Non-javascript macros one the other hand exist at first only
>>>>> within the tiddler they where defined in. So for example if you have a
>>>>> tiddler containing the definition for a macro called get-context you
>>>>> would
>>>>> only be able to use this macro in the same tiddler. This is where then
>>>>> the
>>>>> import pragma and tag $:/tags/Macro come in. Import is used as you
>>>>> have
>>>>> done to allow use of a specific macro in the tiddler it was imported
>>>>> to.
>>>>> The tag $:/tags/Macro on the other hand allows you to mark the macro
>>>>> as
>>>>> global so that you can use it where ever you want without having to
>>>>> specifically import it each time. This is were the exception you
>>>>> reference
>>>>> comes in. Since the startup actions run before the tagged macros are
>>>>> processed to make them globally available you need to import
>>>>> non-javascript
>>>>> macros even if they are properly tagged.
>>>>>
>>>>>
>>>>> Hope you can take away at least something from this and it wasn't too
>>>>> confusing.
>>>>>
>>>>> Happy Sunday for you as well.
>>>>>
>>>>>
>>>>>
>>>>> On Sunday, 13 September 2020 20:47:35 UTC+2, Charlie Veniot wrote:
>>>>>>
>>>>>> G'day Felicia,
>>>>>>
>>>>>> Hi Charlie,
>>>>>>>
>>>>>>> love the concept and very impressiv what you managed to put
>>>>>>> together, thank you for sharing.
>>>>>>>
>>>>>>
>>>>>> Thank-you! Of course, let's keep in mind that, in martial arts
>>>>>> terms, I'm not quite a TiddlyWiki yellow belt yet, so I'm sure there are
>>>>>> many things that could be improved !
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> If you don't mind asking, is there a specific reason for placing the
>>>>>>> decision for what to transclude in the two templates themselves and
>>>>>>> always
>>>>>>> calling both of them?
>>>>>>> Personally I would have put the decision in the root tiddler - e.g.
>>>>>>> TiddlyWiki Title - via a match filter and only called what was needed,
>>>>>>> so I
>>>>>>> wonder if there is something I am missing/not thinking about or if it
>>>>>>> is
>>>>>>> just another case of multiple ways to achieve the same result.
>>>>>>>
>>>>>>
>>>>>> I suspect that you are talking about this way of deciding what to
>>>>>> show based on context: {{TiddlyWiki Title 1||tPr}}{{TiddlyWiki Title
>>>>>> 2||tOg}}
>>>>>>
>>>>>> I chose that way of doing things because I'm having a hard time
>>>>>> wrapping my mind around filters, but I think I've got transclusion
>>>>>> templates down pat.
>>>>>>
>>>>>> So I saw that mechanism as a quick (and non-cryptic) and easily
>>>>>> repeatable method across the board, for example:
>>>>>>
>>>>>> - the "content" tiddler (included in my "navigation" tiddler that
>>>>>> shows in the sidebar) has {{Contents (Product
>>>>>> Reviews)||tPr}}{{Contents
>>>>>> (Urban Off Gridding)||tOg}} to show different navigation links
>>>>>> depending on
>>>>>> context
>>>>>> - I may want to show other tiddlers different ways depending on
>>>>>> context ...
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Oh and one thing I noticed, just as an info: Since getstartupcontext
>>>>>>> is a javascript macro you don't actually need to import it. Unlike
>>>>>>> normal
>>>>>>> macros javascript macros are always global.
>>>>>>>
>>>>>>
>>>>>> Maybe I misunderstood something when I put that import there. I
>>>>>> thought that "StartupAction" tiddlers, because they are processed so
>>>>>> early,
>>>>>> didn't have access to any macros unless they are imported. Does that
>>>>>> just
>>>>>> apply to non-javascript macros ?
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Felicia
>>>>>>>
>>>>>>
>>>>>> Cheers, best regards, and Happy Sunday !
>>>>>>
>>>>>>
>>>>>
--
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/40d88705-4e80-4e74-ab6b-f3603f1f18f5o%40googlegroups.com.
charlieWiki.json
Description: application/json
