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 tiddlywiki+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. 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.