User Tools

Site Tools


pracro:post-commit-hook

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
pracro:post-commit-hook [2011/12/02 08:49] devapracro:post-commit-hook [2011/12/02 13:35] (current) deva
Line 1: Line 1:
 ======Post-Commit-Hook design====== ======Post-Commit-Hook design======
 A method for running a script on session data is needed on session-commit (possibly also discard?) in order to for example be able to post data to external databases when the data are commit to the pracro database. A method for running a script on session data is needed on session-commit (possibly also discard?) in order to for example be able to post data to external databases when the data are commit to the pracro database.
-The mechanism should be designed so that it is also able to handle journal commits and thereby replacing the existing ''<resume>'' tag:+The post-commit-hook scripts are to be executed //after// the commit has been performed successfully to the database. 
 + 
 +The mechanism should be designed so that it is also able to handle journal commits to pcpraxis (currently handled in c++ via upload server) and thereby replacing part of the functionality in the existing ''<resume>'' tag:
 <code xml> <code xml>
 <?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
Line 18: Line 20:
 What should be available to the scripts on run-time? What should be available to the scripts on run-time?
 All committed values from all template macros. Each macro should have the values stored separately so that overlapping names do not overshadow each others values. All committed values from all template macros. Each macro should have the values stored separately so that overlapping names do not overshadow each others values.
 +All generated resume texts must equally be available in order for the script to be able to commit data to the pcpraxis journal.
 +The data can therefore be made available in a preloaded map hierarchy of macros/names/value in the following manner:
 +<code lua>
 +value = vars['macro1']['name']
 +</code>
 +All resume texts are stored with the '''resume''' name making it possible iterate the macros and producing the complete journal text by simple concatenation.
 +An important feature of this list is that the native order of the macros are the same as in the template - **NOT** sorted alphabetically or similar!.
 +
 +It is considered to read out value fields using a function instead in order to prevent setting the values:
 +<code lua>
 +value = getValue('macro1', 'name')
 +</code>
 +This method will also require a function to retrieve the macro list as well as field list from a specific macro since the above function also prevents macro iteration:
 +<code lua>
 +macrolist = getMacroList()
 +fieldlist = getFieldList('macro1')
 +</code>
 +This solution is however fairly ugly. Setting the map from the first method to read-only (or const if you will) would much be prefered.
  
 =====Script placement===== =====Script placement=====
 A single scripting section should be stored in the template file. A single scripting section should be stored in the template file.
 Scripting sections should be included from each macro file in order to the macro-specific scripts where they belong (also share if the macro is used in multiple templates). Scripting sections should be included from each macro file in order to the macro-specific scripts where they belong (also share if the macro is used in multiple templates).
 +<code xml>
 +<?xml version='1.0' encoding='UTF-8'?>
 +<template name="mytemplate" version="1.0" title="My Template" oncommit="func1()" ondiscard="func2()">
 +  <scripts>
 +    <script>
 +      function func1()
 +        -- do something useful
 +      end
 +
 +      function func2()
 +        -- do something useful
 +      end
 +    </script>
 +  </scripts>
 +  <macro name="macro1"/>
 +   .
 +   .
 +   .
 +</code>
 +
 +A similar solution is to be used in the individual macros (ie. oncommit/ondiscard attributes in the macro tag).
 +Each macros scripts are to be loaded in turn in a clean namespace containing only the values of the current macro (again to avoid naming conflicts) and executed in the same order in which they occur in the template.
 +
 +The template scripts are to be executed //before// the macro scripts.
 +
 +<code xml>
 +<?xml version='1.0' encoding='UTF-8'?>
 +<macro name="mymacro" version="1.0" oncommit="func1()" ondiscard="func2()">
 +  <oncommit>
 +    <script>
 +      function func1()
 +        -- do something useful
 +      end
 +
 +      function func2()
 +        -- do something useful
 +      end
 +    </script>
 +  </oncommit>
 +   .
 +   .
 +   .
 +</code>
  
 =====Resume scripts===== =====Resume scripts=====
 The resume scripts cannot directly be replaced by a single on-commit script since the resumes are used dynamically while the template is being edited (to show resumes in collapsed macros). The resume scripts cannot directly be replaced by a single on-commit script since the resumes are used dynamically while the template is being edited (to show resumes in collapsed macros).
  
pracro/post-commit-hook.1322812152.txt.gz · Last modified: 2011/12/02 08:49 by deva