Thank you for the compliment, I am glad it is understandable.
And while there are definitely people in this group with far more knowledge
then me I am happy to help when I can.
On Monday, 14 September 2020 16:28:33 UTC+2, Charlie Veniot wrote:
>
> Holy guacamole, that is a thing of beauty.
>
> I think I get it. Seeing a macro and filter in the context of some thing
> I want to do, that kind of practical perspective makes things pretty clear.
>
> Thank-you so much ! I have to figure out how to intertwingle some
> studying time (for all of this) with all of my little projects.
>
> FUN!
>
> On Monday, September 14, 2020 at 8:31:27 AM UTC-3, Felicia Crow wrote:
>>
>> 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 tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/b50d090b-08a9-4384-a25d-7e545a34d1e9o%40googlegroups.com.
