* Does anyone have a code snippet for this?
- ColeValleyGirl
- Megastar
- Posts: 5465
- Joined: 28 Dec 2005 22:02
- Family Historian: V7
- Location: Cirencester, Gloucestershire
- Contact:
Does anyone have a code snippet for this?
Before I embark on writing one, does anyone have a Lua code snippet to convert Facts of a specified type into Note records, and to convert selected Note records into Facts of a specified type?
Helen Wright
ColeValleyGirl's family history
ColeValleyGirl's family history
- tatewise
- Megastar
- Posts: 28341
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Does anyone have a code snippet for this?
I don't have a snippet for that, but the plugins:code_snippets:copy_child_branch_fields|> Copy Child Branch Fields (code snippet) might be a good starting point, because that parses the nested fields within a nominated Fact.
The CopyBranch(...) statement fhSetValue_Copy(...) would need to become a Note text composing function.
Probably the best solution would be a table.insert(...) and when the parsing completes then use table.concat(...) and fhSetValueAsText(...) to save to the Note record.
Have you considered how to identify each Fact field as a labelled text line in the Note record?
It will have to cope with fields nested within fields to an arbitrary depth.
e.g.
1 Occupation: Labourer
2 Date: 5 Jan 1953
2 Place: Lewisham, London, England
2 Source: @S123@
3 Media: @O321@
3 Where: Page 25
3 Data:
4 Date: 1953
4 Text: Transcript
3 Note: @N21@
That will allow the reverse process to parse those labelled text lines using a complementary version of the code snippet.
Has your code got to cope with EVERY possible Fact syntax, nested fields, linked records, etc?
If so, how will it cope with links to Fact Witness, Note, Source, Media and (rarely) Family records?
Have you considered Family Facts (such as Marriage & Divorce) and how to identify Custom Facts/Attributes.
The CopyBranch(...) statement fhSetValue_Copy(...) would need to become a Note text composing function.
Probably the best solution would be a table.insert(...) and when the parsing completes then use table.concat(...) and fhSetValueAsText(...) to save to the Note record.
Have you considered how to identify each Fact field as a labelled text line in the Note record?
It will have to cope with fields nested within fields to an arbitrary depth.
e.g.
1 Occupation: Labourer
2 Date: 5 Jan 1953
2 Place: Lewisham, London, England
2 Source: @S123@
3 Media: @O321@
3 Where: Page 25
3 Data:
4 Date: 1953
4 Text: Transcript
3 Note: @N21@
That will allow the reverse process to parse those labelled text lines using a complementary version of the code snippet.
Has your code got to cope with EVERY possible Fact syntax, nested fields, linked records, etc?
If so, how will it cope with links to Fact Witness, Note, Source, Media and (rarely) Family records?
Have you considered Family Facts (such as Marriage & Divorce) and how to identify Custom Facts/Attributes.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- ColeValleyGirl
- Megastar
- Posts: 5465
- Joined: 28 Dec 2005 22:02
- Family Historian: V7
- Location: Cirencester, Gloucestershire
- Contact:
Re: Does anyone have a code snippet for this?
Thanks, Mike. These will be very specific facts (Research Tasks for Individuals created by version 1 of the Research Planner plugin -- attributes with no Place or Address fields but optionally an attribute value and a fact date).
Going from Facts to Notes, any Source details will become Source details for the Note record; and the Fact note will become the content of the Note record (prepended with the Attribute and the Fact Date if there is one.) The Note record will be linked to the individual who owned the Fact. The Fact will be left in place for the user to delete when they're happy with the conversion.
Going from Notes to Facts, the Note text will become the Fact Note with a piece of labelled text taken out to become the attribute value (if the text exists). Source details will become the Source details for the Fact. Fact Date will be left blank. The Fact will be linked to the user to whom the Note was linked. The Note will be left in place for the user to delete.
Going from Facts to Notes, any Source details will become Source details for the Note record; and the Fact note will become the content of the Note record (prepended with the Attribute and the Fact Date if there is one.) The Note record will be linked to the individual who owned the Fact. The Fact will be left in place for the user to delete when they're happy with the conversion.
Going from Notes to Facts, the Note text will become the Fact Note with a piece of labelled text taken out to become the attribute value (if the text exists). Source details will become the Source details for the Fact. Fact Date will be left blank. The Fact will be linked to the user to whom the Note was linked. The Note will be left in place for the user to delete.
Helen Wright
ColeValleyGirl's family history
ColeValleyGirl's family history
- tatewise
- Megastar
- Posts: 28341
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Does anyone have a code snippet for this?
OK, that does simplify things a great deal.
Presumably the labelled text lines for Attribute and Date will be distinct enough to avoid them ever occurring in Note text, or will that also have a label?
Have you considered what happens if a user edits the Research Task Fact or the derived Note record?
That may introduce extra Fact fields or corrupt the Note layout; may be serves them right?
Do the Facts and Notes to be reviewed and deleted need to be 'marked' in some way so the user can easily locate them? e.g. Facts could gain a unique field, and Note records gain a Custom Id.
Presumably the labelled text lines for Attribute and Date will be distinct enough to avoid them ever occurring in Note text, or will that also have a label?
Have you considered what happens if a user edits the Research Task Fact or the derived Note record?
That may introduce extra Fact fields or corrupt the Note layout; may be serves them right?
Do the Facts and Notes to be reviewed and deleted need to be 'marked' in some way so the user can easily locate them? e.g. Facts could gain a unique field, and Note records gain a Custom Id.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- ColeValleyGirl
- Megastar
- Posts: 5465
- Joined: 28 Dec 2005 22:02
- Family Historian: V7
- Location: Cirencester, Gloucestershire
- Contact:
Re: Does anyone have a code snippet for this?
Attribute will be labelled with a label configured by the user; and Fact Date will be labelled "Due Date:" (or I might just ditch the Fact Date -- it doesn't serve any real purpose in a Note; it's just optionally available for a user to sort Facts more finely that the Fact timeframe allows.)
If the user edits the Fact definition to include extra fields, they won't be transferred.
Converted Tasks will acquire a #ConvertedTag and the next version of the Research Planner will come with queries (one for Facts, one for Notes) that can filter on tags in the Note text (as well as a number of other fields). I may also include a Utility in the Plugin to display a result set that includes Notes and Facts. (It's a pity that Plugins can only have a single Result Set...)
This conversion is intended to be a tool to help people change how Research Tasks are recorded -- the plugin will offer options for Facts or Notes, and people who have started off using one method may want to change to the other. I don't expect it to be used very often.
If the user edits the Fact definition to include extra fields, they won't be transferred.
Converted Tasks will acquire a #ConvertedTag and the next version of the Research Planner will come with queries (one for Facts, one for Notes) that can filter on tags in the Note text (as well as a number of other fields). I may also include a Utility in the Plugin to display a result set that includes Notes and Facts. (It's a pity that Plugins can only have a single Result Set...)
This conversion is intended to be a tool to help people change how Research Tasks are recorded -- the plugin will offer options for Facts or Notes, and people who have started off using one method may want to change to the other. I don't expect it to be used very often.
Helen Wright
ColeValleyGirl's family history
ColeValleyGirl's family history
- tatewise
- Megastar
- Posts: 28341
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Does anyone have a code snippet for this?
OK, understood.
It is probably of no consequence, but if a user runs a Plugin like Order Facts by Sort Date then every Research Task Fact will gain LMO Sort Date subfields, etc.
It is probably of no consequence, but if a user runs a Plugin like Order Facts by Sort Date then every Research Task Fact will gain LMO Sort Date subfields, etc.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- ColeValleyGirl
- Megastar
- Posts: 5465
- Joined: 28 Dec 2005 22:02
- Family Historian: V7
- Location: Cirencester, Gloucestershire
- Contact:
Re: Does anyone have a code snippet for this?
That's exactly why the user who has asked for Fact Dates wants them
Helen Wright
ColeValleyGirl's family history
ColeValleyGirl's family history
- tatewise
- Megastar
- Posts: 28341
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Does anyone have a code snippet for this?
But even a Research Task Fact without a Date will gain a default LMO Sort Date structure.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry