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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/4f1d9d83-99c7-4b9a-a070-7d5356d7766do%40googlegroups.com.
