Systems Design Strategy - Centralised logic

[TonyM]

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
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.
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

[coda coder]

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?

[TonyM]

Coda,

What I am suggesting is at a higher conceptual level. I could use bundles or plugins for distributing such tiddlers.

Let me try and say it another way.

Lets say I had one or two key tiddlers that capture the logic, relationships, meaning of fields etc... I can then go and design any tiddler to handle my tiddlers and use the logic, filters etc... Defined in my key tiddlers.

Then if I want to change or enhance my wiki I can make changes in my key tiddlers and this new logic will be reflected everywhere else. Just looking at the key tiddlers will show the logic used. If designed well the logic can be shared and reused easily, without having to look in all wiki tiddlers to workout whats happening.

An example would be task management, defining; new active urgent completed archived etc. An active task may be defined as started but not closed or cancelled. But lets say I later want to introduce onhold, rather than edit every task list widget, I can update my definition of active task to exclude onhold, update my definition of inactive task to include onhold.

Regards
Tony

[@TiddlyTweeter]

cc & tm

I thought cc's note interesting.

IMO if we encouraged PMario a bit more The Bundler might add Delete Facilities. 

IMO JSON mediated adds and subtracts are the easiest & most sensible approach to management of TW scope.

Josiah

[@TiddlyTweeter]

TonyM

I can't answer well as I don't have the skill.

IMO sets of base thingies would be useful orientated to SPECIFIC types of use cases?

I'm not so sure there is a "central" way in TW?

Just fairly crude thinking

Josiah

TonyM wrote:

I just wanted to start a thread on "Centralised logic" in TiddlyWiki, it is a systems design pattern I am interested in developing....

[TonyM]

Josiah et al,

Tiddlywiki is highly plastic, we can do anything with it. As a systems designer I can see how we can develop methods to centralise, or systematise solutions within tiddlywiki, such that complexity can be reduced, logic and algorithums shared more easily and change and innovation accelerated (as if we need more 😅).

For most users they have an idea and can build it with a range of components, often editions, plugins or macros to achive specific things and then there is a longer phase of filling it out to a complete or partial solution. This phase is where we can save a lot of effort by providing systematic solutions similar to my suggestion of macros and filters that capture key application logic that are easier than reverting to unconditioned wikitext/ macros.

I hope to publish an example sooner or later but hoping to see if anyone understands the value and concept to stimulate discussion.

Best wishes
Tony