Hi Tony
You're right, this is a problem area of sorts. However, I'm trying to
justify/compare your approach with PMario's Bundles system, which allows
ad-hoc collections of tiddlers garnered from pretty much anywhere.
Thoughts?
On Thursday, January 3, 2019 at 6:41:20 PM UTC-6, TonyM wrote:
>
> Folks,
>
> I just wanted to start a thread on "Centralised logic" in TiddlyWiki, it
> is a systems design pattern I am interested in developing.
>
> *Background*
>
> TiddlyWiki allows rapid and open development, prototyping and design. It
> is possible to code Various logical tests and responses throughout the
> wiki. This is great for ad hoc solutions.
>
> For example You may have a tiddler that lists done tasks, in which the
> logic to determine what is done is coded, and another tiddler with the
> logic for Work in Progress.
>
> However when you want to transfer logic, business rules, tests and
> conditions between wikis you have to go in search of this logical content
> in one or more places.
>
> *Objective*
> Discuss and document some suggested best practice so such logic can be
> placed in a small number of locations and subsequently referenced from any
> location such that if you wish to change or enhance the rules and logic you
> need only change it once.
>
> Open the ability to share logic independently of its application in
> private wikis.
>
> *Example*
> In one tiddler tagged $:/tags/Macro define a set of logical filters
>
> \define is-task() [tiddler-type[task]
> \define new-task()
> [tiddler-type[task]!has[item-started]!has[item-completed]!has[item-cancelled]]
> \define active-task()
> "[tiddler-type[task]has[item-started]!has[item-completed]!has[item-cancelled]]
> \define completed-task() [tiddler-type[task]has[item-completed]]
> \define in-context() [domain{!!domain}project{!!project}client{!!client}]
> \define new-task-in-context() <<new-task>>
> +[domain{!!domain}project{!!project}client{!!client}]
>
>
> In this case each tiddler will have a field time stamped as needed eg
> item-started item-completed or item-cancelled
>
> Then in a List filter you could use
>
> <$list filter="[is[current]subfilter<new-task>]">
>
> Show if current task is a new task
> </$list>](url)
>
>
> <$list filter="[subfilter<new-task>]">
> List all new tasks not started, closed or completed
> </$list>
>
> <$list filter="[subfilter<active-task>subfilter<in-context>]">
> List all new tasks not started, closed or completed in the same "context" as
> the current tiddler.
> </$list>
>
>
>
> *Benefits*
>
>
> 1. You can see in the above the "definition" of a new-task is encoded in
> the first tiddler, and can be changed without reference to all the locations
> where it is used.
> 2. Simply transferring the first tiddler to another wiki allows you to
> continue using the logic you developed in the first wiki, including sharing
> it with the community.
>
> *Discussion*
> The above is one example of this design pattern, I hope in this tread we can
> discuss others that will help the rapid transfer of design logic between
> wikis and community members.
> My Example could be called a "subfilter set".
>
> Personally I am interested in an open "field definition" pattern., I have a
> great deal of prework done on this.
>
> *What other coding patterns would be useful in a similar way to the above?*
>
> Thanks in advance
> 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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/c64e73fe-eb11-4184-8cd2-84cee668bb9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
