Use Case "Programmatically manage SMW pages' content/wikitext and metadata"

From SMW CindyKate - Main
Component 153401
Jump to: navigation, search

Content

Notice:

Use Case "Programmatically manage SMW pages' content/wikitext and metadata" is part of Application "dataspects".

Background and Reasoning

Make changes to SMW content by running a script that specifies those changes in an easy to understand language.

The changes must

  • be repeatable (idempotent),
  • be reusable,
  • be reversible,
  • be logged and
  • support error recovery (transaction support: referential integrity, consistency).

Aspects

Change assertional content

Assertional content is either in a template field (numbered or names) OR in free text.

Assertional content in free text it is either before the first section OR in a section.

Assertional content can be in numbered or bulleted lists.

Assertional content can be in class/id divs.

  • Template instances existence
  • Template instances order
  • Template instances fields existence
  • Template instances fields values
  • Free text sections
  • Free text

Change terminological content

  • Template names: Best practices: CamelCase, no spaces, only letters and numbers
  • Template fields names: Best practices: CamelCase, no spaces, only letters and numbers, template name as prefix

How can changes be tested?

See all method types currently used.

Using page selecting methods, we specify a source collection (SC) of pages to be changed. This SC can

  • be provided within RAM (allowing for SCS), or
  • be exported to a Git repository (allowing for SCG).

Then, using page changing methods, we iterate SC pages and apply changes to each, thereby creating target collection (TC) pages. This TC can

  • be kept in RAM (requiring TCS), or
  • be exported to a Git repository (allowing for TCG).

Finally, using page selecting methods and change verifying methods, we can verify the changes' correctness.

Tests

SC/TC Wikitext Diffy Test
http://www.rubydoc.info/gems/diffy

Diff a SC page's wikitext to it's corresponding TC wikitext.

How should changes be carried out?

1. Apply changes to a source collection (SC) of pages obtained from a SMW (SCS)...

  • Git-revision-control SC: NO

...and write changes to a target collection (TC) of pages

1.a. on the same/another SMW (TCS) 1.b. in a Git repository (TCG)
  • Git-revision-control TC: NO
  • Publish changes: IMMEDIATELY (no organizational or mechanical SMW-write-lock necessary)
  • This is the "typical synchronize SMWs" use case.
  • Git-revision-control TC: YES
  • Changes are published with a delay (requires organizational or mechanical SMW-write-lock or subsequent change runs)

2. Apply changes to a source collection (SC) of pages obtained from a Git repository (SCG)...

  • Git-revision-control SC: YES
  • Changes are published with a delay (requires organizational or mechanical SMW-write-lock or subsequent change runs)

...and write changes to a target collection (TC) of pages

2.a. in the same/another Git repository (TCG)

2.b. on a SMW (TCS)
  • Git-revision-control TC: YES
  • Git-revision-control TC: NO

smw-cindykate content manage will allow for...

...specifying versatile and flexible wikitext target patterns to be implemented on target pages
#set_template_order_and_adding_new_if_not_existent(templates_order) ⇒ Object
mutate_wikitext.rb
pages3.set_TEMPLATE_ORDER_and_adding_new_if_not_existent(["{{ComponentType 100003", "{{Component"])

Implemented page/wikitext mutation methods (at July 26th 2017)

Module: SMWCindyKate::PagesMutators 

#add_FIELD_to_TEMPLATE_NAME_matching_regex(field, template_name) ⇒ Object
#replace_entire_wikitext_with_WIKITEXT(new_wikitext) ⇒ Object 
Module: SMWCindyKate::WikitextMutators
#add_FIELD_to_TEMPLATE_NAME(new_field, template_name, template_profile = :all_template_calls, replace_existing_field = replace_existing_field=false) ⇒ Object
#set_TEMPLATE_ORDER_and_adding_new_if_not_existent(templates_order) ⇒ Object